[ https://jira.jboss.org/jira/browse/JBTM-610?page=com.atlassian.jira.plugi... ] Andrew Dinn commented on JBTM-610: ---------------------------------- Failure to synchronize on the LockManager calls is not actually the source of this deadlock. Adding the synchronizations will not hep and is probably unnecessary. The problem manifested in the test failure occurs as followd Threads A and B both have the same current acttion A. A includes an instance L in its participants list which inherits from LockManager. Thread A calls L.setlock() setLock synchronizes on LockManager.locksHeldLockObject *** setLock calls super.modified() (i.e. StateManager.modified()) StateManager.modified fetches the current AtomicAction and calls BasicAction.add() which triies to syncrhonize on A^^^ in parallel Thread B calls BasicAction.abort() synchronizing on A *** abort() calls L..topLevelAbort L.topLevelAbort calls L.doRelease() L.doReleasetries to synchronize on LockManager.locksHeldLockObject ^^^ So, the problem is a simple two way deadlock. A and B both obtain a lock at *** and then want the other guy's lock at ^^^. Synchronizing on the Lock/StateManager calls will not stop this deadlock happening because the lock on the action can be taken in BasicAction.abort without going through any of the Lock/StateManager calls. A proper fix requires all paths which can take one lock to already include the other lock. Calls to BasicAction.abort can quite legitimately happen with no reference to Lock/StateManager instances. So it is not reasonable to expect these calls to first obtain the LockManager.locksHeldLockObject. Hence, it will be necessary to synchronize on the current action in StateManager.setlock before synchronizing on the LockManager.locksHeldLockObject and risking an invocation of super.modified(). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JBTM-610?page=com.atlassian.jira.plugi... ] Jonathan Halliday reopened JBTM-610: ------------------------------------ LockManager.java:415: synchronized (currAct) fails to anticipate currAct == null case. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JBTM-610?page=com.atlassian.jira.plugi... ] Work on JBTM-610 started by Mark Little. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira