JBoss Cache
  1. JBoss Cache
  2. JBCACHE-97

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

    Details

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

      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)

        Issue Links

          Activity

          Hide
          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
          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
          Bela Ban
          added a comment -

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

          Show
          Bela Ban
          added a comment - No, this is not fixed. It will be fixed in 1.3
          Hide
          Bela Ban
          added a comment -
          Show
          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
          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
          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
          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
          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
          added a comment -

          This will be fixed as part of JBCACHE-1151

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

          Will be made obsolete with JBCACHE-1151

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

            People

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

              Dates

              • Created:
                Updated:
                Resolved: