When ConcurrencyManager will be locked?

Question

Hi all,
Our application server (OC4J 9.0.3) has encountered a locking problem. With the thread dump listed below, we know that our stateful session bean has been locked with TopLink (9.0.3) 's ConcurrencyManager. May I know under what condition, this manager will be locked? Thank you for the any help offered!
"ApplicationServerThread-23" prio=5 tid=0x3df478 nid=0x2b waiting on monitor [0xc2f80000..0xc2f81a00]
     at java.lang.Object.wait(Native Method)
     at java.lang.Object.wait(Object.java:415)
     at oracle.toplink.internal.helper.ConcurrencyManager.acquire(Unknown Source)
     at oracle.toplink.publicinterface.Session.beginTransaction(Unknown Source)
     at oracle.toplink.publicinterface.UnitOfWork.beginTransaction(Unknown Source)
     at oracle.toplink.publicinterface.UnitOfWork.internalExecuteQuery(Unknown Source)
     at oracle.toplink.publicinterface.Session.executeQuery(Unknown Source)
     at oracle.toplink.publicinterface.Session.executeQuery(Unknown Source)
     at oracle.toplink.publicinterface.Session.executeNonSelectingCall(Unknown Source)
Thanks and regards,
William

Answer 1

Hi Douglas,
Thanks for your kindly advice. Hope the following replies can explain the case in more details.
[qoute]
1. Why are you using a database session per session bean versus a shared server session? Creating a new session for each SB can be expensive.
[qoute]
Our systems runs on a cluster, and we have difficult to synchronize the session cache among different JVM with Toplink 9.0.3. Therefore we choose to use database session per session bean to make sure that we will not have stale data due to cache synchronization problem. To minize the cost paid for the session bean creation, the session bean we used is stateful. It handles all the requests coming from a single user.
>
2. Are you sure you have a dedicated/isolated database session per SB? Getting your database session from the SessionManager will return the same singleton database session on each request.
We creates the session object via the oracle.toplink.sessions.Project object instead of SessionManager. Since the Project object are created with object reflection, I believe all database session object created are isolated.
>
3. Are you sure you do not intentionally or unintentionally have multiple threads accessing the same database session and/or UnitOfWork? Similar to #2
All business logics are executed with the stateful session bean which has a dedicated database session. Since the session bean is stateful, we also have to sychronize all the access to this bean. Unless our application developer has made some silly mistakes to acquire the database session from another stateful session bean and override it with the one our framework provided, it is unlikely we have multiple threads accessing the same database session. Anyway, I will double check this with our application developers as it is the only available possible cause of the error.
[qoute]
As to your issue about not being able to acquire any additional SFSB from the container once the lock has occurred. There is nothing in TopLink that can prevent a session bean from being returned by the container. Is there anything in the full thread dump that indicates container threads are blocked?
With the full thread dump, we noticed that the EJB container (OC4J 9.0.3) was trying to release a timeout stateful session bean.
"TaskManager" prio=5 tid=0x807678 nid=0x12 waiting for monitor entry [0xc3f81000..0xc3f81a00]
     at com.evermind.server.ejb.AbstractEJBObject.isInCall(AbstractEJBObject.java:90)
     at com.evermind.server.ejb.StatefulSessionEJBHome.removeTimedOutSessions(StatefulSessionEJBHome.java:115)
     at com.evermind.server.ejb.EJBTask.run(EJBTask.java:58)
     at com.evermind.util.TaskManager.run(TaskManager.java:181)
     at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(PooledExecutor.java:798)
     at java.lang.Thread.run(Thread.java:479)We suspected that, due to the lock (Object.wait()) occurred with the TopLink, the EJB container cannot release the SFSB successfully. And hence, it blocks the EJB container to return new stateful session bean.
"ApplicationServerThread-16" prio=5 tid=0x36d3f0 nid=0x21 waiting for monitor entry [0xc3680000..0xc3681a00]
     at com.evermind.server.ejb.StatefulSessionEJBHome.getNextID(StatefulSessionEJBHome.java:37)
     at com.evermind.server.ejb.StatefulSessionEJBObject.<init>(StatefulSessionEJBObject.java:40)
     at com.evermind.server.ejb.RemoteStatefulSessionEJBObject.<init>(RemoteStatefulSessionEJBObject.java:16)
     at
...BTW, I am not really familar with EJB. Could we call "Object.wait()" within a session bean?
Moreover, could the TopLink was waiting for a return from database? Could the problem we encountered with be related to database row lock?
Thanks and regards,
William