Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Help: weblogic.ejb.extensions.LockTimedOutException

0 views
Skip to first unread message

newsgroups.bea.com

unread,
Jun 19, 2002, 3:52:32 PM6/19/02
to
Dear All:

I got this exception in our EJB app:
weblogic.ejb.extensions.LockTimedOutException. Please see attached error
message below. It is not happening every time you call the bean. It is
reproducable with patience.

Have you had this kind of problem and more importantly, how to avoid it?

Our env is: Wl51 with sp 10, jdk1.3.02, Sun Solaris Unix, a cluster contains
2 wl instance

Thanks.

Wed Jun 19 14:26:53 EDT 2002:<I> <TX> Transaction (TxC (5488304, xid =
1024502557372_6636, timeout = 300, txState = Marked Rollback, root = null)
rolled back after 300 sec.

[GC 99080K->85533K(130688K), 0.0227977 secs]

Wed Jun 19 14:26:54 EDT 2002:<I> <EJB JAR deployment
/webapp/dtshc/dts/nmc/ejb/nmcejb.jar> Transaction: '1024502557372_6636'
rolled back due to EJB exception:

weblogic.ejb.extensions.LockTimedOutException: Lock for
primaryKey:com.mm.nmc.entity.ProducerOneYearPlanPK@1700fc timed out after
300000 ms.

at
weblogic.ejb.internal.LockManagerImpl.waitForLock(LockManagerImpl.java:53)

at weblogic.ejb.internal.LockManagerImpl.lock(LockManagerImpl.java:146)

at weblogic.ejb.internal.LockManagerImpl.lock(LockManagerImpl.java:81)

at weblogic.ejb.internal.StatefulEJBCache.bind(StatefulEJBCache.java:456)

at
weblogic.ejb.internal.StatefulEJBObject.getContextForInvoke(StatefulEJBObjec
t.java:162)

at weblogic.ejb.internal.BaseEJBObject.preInvoke(BaseEJBObject.java:476)

at
com.mm.nmc.entity.ProducerOneYearPlanEJBEOImpl.getData(ProducerOneYearPlanEJ
BEOImpl.java:979)

at
com.mm.nmc.session.PersonalTacticalSessionEJB.getTacticalPlanGoals(PersonalT
acticalSessionEJB.java:200)

at
com.mm.nmc.session.PersonalTacticalSessionEJB.getPersonalTacticalPlan(Person
alTacticalSessionEJB.java:165)

at
com.mm.nmc.session.PersonalTacticalSessionEJB.getPersonalTacticalPlan(Person
alTacticalSessionEJB.java:155)

at
com.mm.nmc.session.PersonalTacticalSessionEJBEOImpl.getPersonalTacticalPlan(
PersonalTacticalSessionEJBEOImpl.java:340)

at
com.mm.nmc.session.PersonalTacticalSessionEJBEOImpl_WLSkel.invoke(PersonalTa
cticalSessionEJBEOImpl_WLSkel.java:167)

at
weblogic.rmi.extensions.BasicServerObjectAdapter.invoke(BasicServerObjectAda
pter.java:347)

at
weblogic.rmi.extensions.BasicRequestHandler.handleRequest(BasicRequestHandle
r.java:86)

at
weblogic.rmi.internal.BasicExecuteRequest.execute(BasicExecuteRequest.java:1
5)

at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:129)


--
Jiancai He
http://www.hefamily.com


ludovic le goff

unread,
Jun 21, 2002, 8:54:14 AM6/21/02
to
Hello,

Basically, it means two (or more) different threads are trying to get an
exclusive lock on the same entity bean or stateful session bean at the same
time. One of the locks eventually times out and this exception is thrown.

There are several things that could cause this, for instance:

- Two threads trying to invoke a method on the same stateful session bean at
the same time. The EJB 1.1 spec states that the server must detect this
condition and throw a RemoteException to all subsequent callers.
LockTimedOutException is a sub-class of java.rmi.RemoteException.

- Two threads are trying to access the same entity bean instance inside a
single server in the cluster, and the caller holding the lock does not
finish fast enough.

You might want to check if you have declared the Remote and home interface
in your jsp/servlet as global variable. And since it's global, instance
getting overridden every time. That's why both the two request end up in
using the same EJBObject.

You should changed your code and make the remote/home interface variable
declaration as local i.e. within the scope of a single request.
Then you should not see any problem. Both the threads will use different
EJBObjects and hence you should not see any exceptions.

You need to code in such a way as to avoid deadlocks. For instance, if
more than one client accesses the EJBs in different order, a deadlock may
occur. This deadlock is detected and after a certain timeout (5 minutes by
default), the deadlock is removed and one of the clients gets a
LockTimedOutException. For example, if one request in your application has
entity Account 1 (by doing an ejbFindByPrimaryKey) and is then about to get
Customer 1, and if at the same time another request in another business
method has got Customer 1 and is waiting for Account 1, you'll get a
deadlock and a LockTimedOutException after 5 minutes. You could avoid this
by include the code in a synchronized block. You could also get a deadlock
if you're making a reentrant call, e.g., A calls B which calls back to A.

If you haven't already seen this, here's a blurb from "Locking Model for
Entity EJBs" at
http://www.weblogic.com/docs51/classdocs/API_ejb/EJB_environment.html#108796
7 that you might find interesting:

The EJB 1.1 container in WebLogic Server Version 5.1 uses a pessimistic
locking mechanism for entity EJB instances. As clients enlist an EJB or EJB
method in a transaction, WebLogic Server places an exclusive lock on the EJB
instance or method for the duration of the transaction. Other clients
requesting the same EJB or method block until the current transaction
completes.

This method of locking provides reliable access to EJB data, and avoids
unnecessary calls to ejbLoad() to refresh the EJB instance's persistent
fields. However, in certain circumstances pessimistic locking may not
provide the best model for concurrent access to the EJB's data. Once a
client has locked an EJB instance, other clients are blocked from the EJB's
data even if they intend only to read the persistent fields.

In a Nutshell the first exception is a consequence of the second.

Hope this helps,
Ludovic.
Developer Relations Engineer
BEA Customer Support
"newsgroups.bea.com" <j...@massmutual.com> a écrit dans le message news:
3d10e101$1...@newsgroups2.bea.com...

newsgroups.bea.com

unread,
Jun 24, 2002, 4:21:03 PM6/24/02
to
Thanks for your message:

In our case, it is entity EJB. The problem only happens in clustered env,
and only happens in one of the servers.

Question: can wl51 use database to manage the concurrent access of entity
EJBs?

Thanks.

Jiancai

"ludovic le goff" <Re...@ToNewsgroup.Only> wrote in message
news:3d13...@newsgroups2.bea.com...

0 new messages