[jbossts-issues] [JBoss JIRA] (JBTM-1350) Deadlock in LockManager

[ https://issues.jboss.org/browse/JBTM-1350?page=com.atlassian.jira.plugin.... ] Michael Musgrove edited comment on JBTM-1350 at 3/20/13 7:24 AM: ----------------------------------------------------------------- The same problem occurs when the commit request comes in via the call com.arjuna.ats.internal.jts.orbspecific.interposition.resources.arjuna.ServerNestedAction.commit_subtransaction (I am attaching the stacktraces) With this route no transaction is associated with the current thread and the deadlock is: * Thread 1: LockManager propagate is called (via commit) which takes two locks Lock1: associated action or StateManager::mutex Lock2: LockManager::locksHeldLockObject * Thread 2: LockManager setlock is called (via a remote client invoking a get operation on HammerObject which extends LockManager) Lock1: associated action or StateManager::mutex Lock2: LockManager::locksHeldLockObject Lock3: StateManager::mutex So if Thread 1 does not have the action associated with the thread but Thread 2 does then we have a classic deadlock. This happens when Thread 1 comes in via ServerNestedAction.commit_subtransaction. Rather than fixing it be associated the transaction with the thread the better solution as follows: * force LockManager propagate to take the StateManager::mutex This nearly works but now we have a lock ordering problem when using intrinsic locks on StateManager (synchronized method calls). * Thread 1: StateManager::forgetAction Lock1: intrinsic lock on HammerObject (synchronized boolean forgetAction) Lock2: StateManager::mutex * Thread 2: StateManager::activate (via LockManager setlock) is called (via a remote client invoking a get operation on HammerObject which extends LockManager) Lock1: associated action or StateManager::mutex Lock2: LockManager::locksHeldLockObject Lock3: StateManager::mutex Lock4: intrinsic lock on HammerObject (synchronized boolean activate) So the two threads are taking the intrinsic lock on HammerObject and StateManager::mutex is different orders causing another deadlock. The solution for this problem is to make sure that the intrinsic lock on HammerObject is taken in the correct order (ie in LockManager::propagate and LockManager::setlock). This appears to resolve the JIRA. was (Author: mmusgrov): The same problem occurs when the commit request comes in via the call com.arjuna.ats.internal.jts.orbspecific.interposition.resources.arjuna.ServerNestedAction.commit_subtransaction (I am attaching the stacktraces) With this route no transaction is associated with the current thread and the deadlock is: * Thread 1: LockManager propagate is called (via commit) which takes two locks Lock1: associated action or StateManager::mutex Lock2: LockManager::locksHeldLockObject Thread 2: LockManager setlock is called (via a remote client invoking a get operation on HammerObject which extends LockManager) Lock1: associated action or StateManager::mutex Lock2: LockManager::locksHeldLockObject Lock3: StateManager::mutex So if Thread 1 does not have the action associated with the thread but Thread 2 does then we have a classic de adlock. This happens when Thread 1 comes in via ServerNestedAction.commit_subtransaction. Rather than fixing i t be associated the transaction with the thread the better solution as follows: - force LockManager propagate to take the StateManager::mutex This nearly works but now we have a lock ordering problem when using intrinsic locks on StateManager (synchronized method calls). Thread 1: StateManager::forgetAction Lock1: intrinsic lock on HammerObject (synchronized boolean forgetAction) Lock2: StateManager::mutex Thread 2: StateManager::activate (via LockManager setlock) is called (via a remote client invoking a get operation on HammerObject which extends LockManager) Lock1: associated action or StateManager::mutex Lock2: LockManager::locksHeldLockObject Lock3: StateManager::mutex Lock4: intrinsic lock on HammerObject (synchronized boolean activate) So the two threads are taking the intrinsic lock on HammerObject and StateManager::mutex is different orders causing another deadlock. The solution for this problem is to make sure that the intrinsic lock on HammerObject is taken in the correct order (ie in LockManager::propagate and LockManager::setlock). This appears to resolve the JIRA. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira