Uploaded image for project: 'JBoss Cache'
  1. JBoss Cache
  2. JBCACHE-97

ReadWriteLockWithUpgrade: UpgradeException with more than 1 reader/writer waiting to upgrade lock

    Details

    • Type: Bug
    • Status: Resolved (View Workflow)
    • Priority: Major
    • Resolution: Won't Fix
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: Clustering
    • Labels:
      None
    • Estimated Difficulty:
      High

      Description

      TxDeadlockUnitTestCase has 2 methods that show the following stack traces:

      testMoreThanOneUpgrader:
      Upgrader#0: get(/a/b/c)
      Upgrader#1: get(/a/b/c)
      main: locks:
      /a (read owners=[<null>:2, <null>:1])
      /b (read owners=[<null>:2, <null>:1])
      /c (read owners=[<null>:2, <null>:1])

      Upgrader#0: put(/a/b/c)
      Upgrader#1: put(/a/b/c)
      Upgrader#1: org.jboss.cache.lock.LockingException: acquireWriteLock(): lock upgrade failed for /a/b/c (caller=<null>:2); - nested throwable: (org.jboss.cache.lock.UpgradeException: upgradeLockAttempt(): more than one reader trying to simultaneously upgrade to write lock)
      Upgrader#0: org.jboss.cache.lock.TimeoutException: upgrade lock for /a/b/c could not be acquired after 3000 ms. Lock map ownership Read lock owners: [<null>:2]
      Write lock owner: null
      (caller=<null>:1)

      org.jboss.cache.lock.TimeoutException: upgrade lock for /a/b/c could not be acquired after 3000 ms. Lock map ownership Read lock owners: [<null>:2]
      Write lock owner: null
      (caller=<null>:1)
      at org.jboss.cache.lock.IdentityLock.acquireWriteLock(IdentityLock.java:155)
      at org.jboss.cache.Node.acquireWriteLock(Node.java:448)
      at org.jboss.cache.Node.acquire(Node.java:417)
      at org.jboss.cache.interceptors.LockInterceptor.lock(LockInterceptor.java:199)
      at org.jboss.cache.interceptors.LockInterceptor.invoke(LockInterceptor.java:144)
      at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:40)
      at org.jboss.cache.interceptors.CreateIfNotExistsInterceptor.invoke(CreateIfNotExistsInterceptor.java:145)
      at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:40)
      at org.jboss.cache.interceptors.UnlockInterceptor.invoke(UnlockInterceptor.java:35)
      at org.jboss.cache.TreeCache.invokeMethod(TreeCache.java:2998)
      at org.jboss.cache.TreeCache.put(TreeCache.java:1657)
      at org.jboss.test.cache.test.local.TxDeadlockUnitTestCase$MyUpgrader._run(TxDeadlockUnitTestCase.java:346)
      at org.jboss.test.cache.test.local.TxDeadlockUnitTestCase$GenericThread.run(TxDeadlockUnitTestCase.java:213)
      at org.jboss.test.cache.test.local.TxDeadlockUnitTestCase$GenericThread.run(TxDeadlockUnitTestCase.java:213)

      and

      testConcurrentUpgrade():
      MyThread#1: get(/a/b/c)
      MyThread#2: get(/a/b/c)
      MyThread#2: done, locks:
      /a (read owners=[<null>:2])
      /b (read owners=[<null>:2])
      /c (read owners=[<null>:2])

      MyThread#1: done, locks:
      /a (read owners=[<null>:2, <null>:1])
      /b (read owners=[<null>:2, <null>:1])
      /c (read owners=[<null>:2, <null>:1])

      MyThread#2: put(/a/b/c)
      MyThread#1: put(/a/b/c)
      MyThread#1: org.jboss.cache.lock.LockingException: acquireWriteLock(): lock upgrade failed for /a/b/c (caller=<null>:1); - nested throwable: (org.jboss.cache.lock.UpgradeException: upgradeLockAttempt(): more than one reader trying to simultaneously upgrade to write lock)
      MyThread#2: org.jboss.cache.lock.TimeoutException: upgrade lock for /a/b/c could not be acquired after 3000 ms. Lock map ownership Read lock owners: [<null>:1]
      Write lock owner: null
      (caller=<null>:2)

      org.jboss.cache.lock.TimeoutException: upgrade lock for /a/b/c could not be acquired after 3000 ms. Lock map ownership Read lock owners: [<null>:1]
      Write lock owner: null
      (caller=<null>:2)
      at org.jboss.cache.lock.IdentityLock.acquireWriteLock(IdentityLock.java:155)
      at org.jboss.cache.Node.acquireWriteLock(Node.java:448)
      at org.jboss.cache.Node.acquire(Node.java:417)
      at org.jboss.cache.interceptors.LockInterceptor.lock(LockInterceptor.java:199)
      at org.jboss.cache.interceptors.LockInterceptor.invoke(LockInterceptor.java:144)
      at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:40)
      at org.jboss.cache.interceptors.CreateIfNotExistsInterceptor.invoke(CreateIfNotExistsInterceptor.java:145)
      at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:40)
      at org.jboss.cache.interceptors.UnlockInterceptor.invoke(UnlockInterceptor.java:35)
      at org.jboss.cache.TreeCache.invokeMethod(TreeCache.java:2998)
      at org.jboss.cache.TreeCache.put(TreeCache.java:1657)
      at org.jboss.test.cache.test.local.TxDeadlockUnitTestCase$MyThread._run(TxDeadlockUnitTestCase.java:317)
      at org.jboss.test.cache.test.local.TxDeadlockUnitTestCase$GenericThread.run(TxDeadlockUnitTestCase.java:213)
      at org.jboss.test.cache.test.local.TxDeadlockUnitTestCase$GenericThread.run(TxDeadlockUnitTestCase.java:213)

        Gliffy Diagrams

          Issue Links

            Activity

            Hide
            rajanik Rajanikanth Jayaseelan added a comment -

            Hi,

            Can you please let us know if this issue is fixed. We are using Jboss Cache in our highly scalable bank Application adn we always get this scenario and error.

            Thanks,
            Cheers
            rajani

            Show
            rajanik Rajanikanth Jayaseelan added a comment - Hi, Can you please let us know if this issue is fixed. We are using Jboss Cache in our highly scalable bank Application adn we always get this scenario and error. Thanks, Cheers rajani
            Hide
            belaban Bela Ban added a comment -

            No, this is not fixed. It will be fixed in 1.3

            Show
            belaban Bela Ban added a comment - No, this is not fixed. It will be fixed in 1.3
            Hide
            belaban Bela Ban added a comment -
            Show
            belaban Bela Ban added a comment - See my question and the suggested answer at http://www.nabble.com/Upgrading-a-RL-to-WL-in-ReentrantReadWriteLock-tf2762910.html#a7717457
            Hide
            jason.greene Jason Greene added a comment -

            After investigating this, it is not possible to fix this without breaking repeatable read semantics. So if you don't want to handle this exception set the isolation level to READ_COMMITTED, or use optimistic locking.

            Show
            jason.greene Jason Greene added a comment - After investigating this, it is not possible to fix this without breaking repeatable read semantics. So if you don't want to handle this exception set the isolation level to READ_COMMITTED, or use optimistic locking.
            Hide
            jason.greene Jason Greene added a comment -

            I just realized there might be a way to make this work in some scenarios, need to investigate further

            Show
            jason.greene Jason Greene added a comment - I just realized there might be a way to make this work in some scenarios, need to investigate further
            Hide
            jason.greene Jason Greene added a comment -

            This will be fixed as part of JBCACHE-1151

            Show
            jason.greene Jason Greene added a comment - This will be fixed as part of JBCACHE-1151
            Hide
            manik Manik Surtani added a comment -

            Will be made obsolete with JBCACHE-1151

            Show
            manik Manik Surtani added a comment - Will be made obsolete with JBCACHE-1151

              People

              • Assignee:
                jason.greene Jason Greene
                Reporter:
                belaban Bela Ban
              • Votes:
                16 Vote for this issue
                Watchers:
                12 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved:

                  Development