Bugs item #635899, was opened at 2002-11-09 12:34 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=635899&group_id=22866
>Category: JBossServer Group: v3.0 Rabbit Hole >Status: Closed >Resolution: Accepted Priority: 7 Submitted By: Michael Lipp (mlipp) >Assigned to: Adrian Brock (ejort) 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). ---------------------------------------------------------------------- >Comment By: Adrian Brock (ejort) Date: 2002-11-16 09:34 Message: Logged In: YES user_id=9459 This fix has been applied to 2.4, 3.0, 3.2 and HEAD Thank you very much Michael. Regards, Adrian ---------------------------------------------------------------------- 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: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
