Uploaded image for project: 'JBoss Enterprise Application Platform 4 and 5'
  1. JBoss Enterprise Application Platform 4 and 5
  2. JBPAPP-7354 Upgrade JBoss Cache to 3.2.11
  3. JBPAPP-9220

Lock TimeoutException when using a JTS transaction manager under load

XMLWordPrintable

    • Icon: Sub-task Sub-task
    • Resolution: Done
    • Icon: Major Major
    • EAP_EWP 5.2.0
    • EAP_EWP 5.1.2
    • Clustering
    • None
    • Release Notes
    • Hide
      When using a JTS transaction manager, transaction commit could incorrectly share data between threads when under heavy load due to a race condition in JBoss Cache. This could result in lock time-out exceptions as locks were not freed correctly. With this update, the race condition no longer occurs, the transaction commit uses the correct data when using a JTS transaction manager under load, and transactions are committed correctly.
      Show
      When using a JTS transaction manager, transaction commit could incorrectly share data between threads when under heavy load due to a race condition in JBoss Cache. This could result in lock time-out exceptions as locks were not freed correctly. With this update, the race condition no longer occurs, the transaction commit uses the correct data when using a JTS transaction manager under load, and transactions are committed correctly.
    • Documented as Resolved Issue
    • NEW

      After switching to JTS for transactions, "random" lock timeouts occur:

      org.jboss.cache.lock.TimeoutException: Unable to acquire lock on Fqn [/foo] after [15000] milliseconds for requestor [GlobalTransaction:<10.1.2.3:12345>:5]! Lock held by [null]
      at org.jboss.cache.mvcc.MVCCNodeHelper.acquireLock(MVCCNodeHelper.java:157)

              rhn-support-dereed Dennis Reed
              rhn-support-dereed Dennis Reed
              Eva Kopalova Eva Kopalova (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

                Created:
                Updated:
                Resolved: