• Type: Bug
    • Status: Closed (View Workflow)
    • Priority: Major
    • Resolution: Done
    • Affects Version/s: 4.17.0.M1/5.0.0.M1, 4.17.2
    • Fix Version/s: 5.0.0.M3
    • Component/s: Transaction Core
    • Labels:


      A deadlock can occur whilst calling LockManager.setlock if another thread tries to commit a transaction that has the same lock manager as a participant. The attached java stack dump, jstack.16785, (from test com.hp.mwtests.ts.jts.remote.hammer.DistributedHammer2) shows an example. It shows two threads interacting with a remote HammerObject:

      • Thread 1 updates the remote object;
      • Thread 2 commits a transaction that has the same HammerObject instance as a participant;

      Thread 1 calls setlock on HammerObject which synchronizes on BasicAction.Current() and LockManager.locksHeldLockObject and then activates the object (which triggers an object load from the object store). The activate call tries to lock StateManager.mutex and this is where thread 1 deadlocks.

      Meanwhile a commit request is issued which results in Thread 2 running at the same time thread 1 is calling activate. The commit asks HammerObject to prepare and commit. The participant commit asks HammerObject to release any locks it has held (LockManager.releaseAll). This call first tries to lock BasicAction.Current() which is null during commit time (since commit disassociates the transaction from the thread before committing the participants). Instead it locks StateManager.mutex which succeeds. Then it tries to lock LockManager.locksHeldLockObject and that is where Thread 2 deadlocks.

      Note that the problem arises because Thread 2 gets null when it calls BasicAction.Current() and instead locks StateManager.mutex. If BasicAction.Current() was not null thread 2 would try to lock it but would not obtain the lock until thread 1 had completed the activate call and released BasicAction.Current() thus allowing thread 2 to continue as normal.

        Gliffy Diagrams


          1. deadlock_via_intrinsic_lock
            18 kB
            Michael Musgrove
          2. deadlock_via_ServerNestedAction
            20 kB
            Michael Musgrove
          3. jstack.16785
            16 kB
            Michael Musgrove

            Issue Links



                • Assignee:
                  mmusgrov Michael Musgrove
                  mmusgrov Michael Musgrove
                • Votes:
                  0 Vote for this issue
                  2 Start watching this issue


                  • Created:

                    Time Tracking

                    Original Estimate - 1 day
                    Remaining Estimate - 1 day
                    Time Spent - Not Specified
                    Not Specified