Bugs item #635899, was opened at 2002-11-09 13:34 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=635899&group_id=22866
Category: None Group: v3.0 Rabbit Hole Status: Open Resolution: None >Priority: 7 Submitted By: Michael Lipp (mlipp) Assigned to: Nobody/Anonymous (nobody) Summary: Bug in deadlock detection (with fix) Initial Comment: After starting to use massive parallel requests, our application has started to "hang", suggesting an undetected deadlock situation. It took me most of the last week to track down what happens: EJB X is currently used by transaction Tb. (1) Tb(X) In comes another request Tc that needs Tb (2) Tc --> Tb(X) and yet another request that needs Tb and already has EJB Y locked (3) Td(Y) --> Tb(X) Now Tb terminates and releases X which is taken over by Tc (next in queue). (4) Tc(X) Tc and Td are woken up (actually the associated thread is woken up, but as there is a one-to-one association I'll continue to speak of transactions being woken up). You can, however, not tell in which sequence. Let's first look at the "good" sequence: (good) Td awakes, removes its entry from the waiting table, finds that X is locked by Tc and adds a new "adjusted" entry in the waiting table (5) Td(Y) --> Tc(X) Now Tc awakes and while proceeding, wants a lock on Y. The lock handling on Y uses Td (current locker of Y) as key for a lookup in the waiting map, finds Tc which matches the transaction requesting the lock and successfully detectes the deadlock. Now the bad sequence: (bad) Tc awakes and while proceeding, wants a lock on Y. The lock handling on Y uses Td as key for a lookup in the waiting map and finds Tb (because adjusting has not taken place yet). As this has nothing to do with the requesting Tc, no deadlock ist detected and things proceed, i.e. Tc waits for Y (5') Tc(X) --> Td(Y) Now Td wakes up, removes its entry from the waiting table, finds that X is locked by Tc and adds a new "adjusted" entry in the waiting table: (6') Td(Y) --> Tc(X) Here you are, run into the deadlock and nobody has noticed. The fix I propose is very simple. Do not hold the transitions as values in the waiting table. Rather hold the QueuedPessimisticEJBLocks and get the associated transactions. Thus any change of locking transition is reflected in the waiting table immediately. Now things run correctly with our application. Of course, we get the deadlock exceptions, but that is something any properly programmed EJB client has to handle (by simply repeating the call, if not using client transactions). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=635899&group_id=22866 ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
