Bugs item #601097, was opened at 2002-08-28 12:45
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=601097&group_id=22866
Category: JBossServer
Group: v3.0 Rabbit Hole
Status: Open
Resolution: None
Priority: 5
Submitted By: Stephen Coy (scoy)
Assigned to: Nobody/Anonymous (nobody)
Summary: Race cond in QueuedPessimisticEJBLock
Initial Comment:
I believe that I have uncovered a race condition in
QueuedPessimisticEJBLock that
causes the deadlock detector to misfire.
We have an entity bean with interface:
public interface Designation
extends javax.ejb.EJBObject
{
public java.lang.String getCode( ) throws
java.rmi.RemoteException;
public java.lang.String getDisplay( ) throws
java.rmi.RemoteException;
}
The bean is configured with commit option A and the "get*"
methods are read-only.
Two threads A and B each begin a new trx and begin iterating over
a collection of
these beans, calling getCode and getDisplay on each one. Thread
A is running
slightly ahead of thread B. (we are building a popup menu in a
JSP).
At some point, thread A is delayed slightly while it loads data
during its invoke
of getCode and thread B catches up with it. Thread B blocks in
QueuedPessimisticEJBLock.waitForTx because thread A has the
lock. Prior to
blocking it adds an entry to the BeanLockSupport.waiting
HashMap.
Thread A completes its invokation of getCode and the following
methods of
QueuedPessimisticEJBLock get called:
1. endInvocation
2. endTransaction
3. nextTransaction
Amongst other things, nextTransaction sets the lock's tx to that of
thread B
and wakes up thread B.
This is where the race begins.
Thread A subsequently calls getDisplay on the same bean and
enters waitForTx.
It's mi tx is now different to the lock's tx, so it enters the wait loop
and adds an entry to the BeanLockSupport.waiting HashMap.
Thread B has not yet run to the end of waitForTx, so it's entry is
still
sitting in the BeanLockSupport.waiting HashMap.
Thread A runs BeanLockSupport.deadlockDetection and it finds
thread B's
entry that says it's waiting on thread A's lock, because thread B
has not
got around to removing it yet.
BeanLockSupport.deadlockDetection throws
ApplicationDeadlockException, even
though there is no real deadlock present.
I'm going to try and fix it, but I know this is a sensitive area and
you guys
will probably have your own ideas on the best way.
I'm running MacOS 10.1.5 and the corresponding Apple 1.3.1
JRE, for what it's worth.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=601097&group_id=22866
-------------------------------------------------------
This sf.net email is sponsored by: Jabber - The world's fastest growing
real-time communications platform! Don't just IM. Build it in!
http://www.jabber.com/osdn/xim
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
