Uploaded image for project: 'JBoss Transaction Manager'
  1. JBoss Transaction Manager
  2. JBTM-2846

Thread-safety problem in BasicAction

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Done
    • Icon: Critical Critical
    • 5.5.3.Final
    • 5.4.0.Final
    • Transaction Core
    • None

      It is possible for multiple threads to have a given transaction association at the same time (com.arjuna.ats.arjuna.coordinator.BasicAction#_childThreads). However, only inconsistent protection is provided for com.arjuna.ats.arjuna.coordinator.BasicAction#actionStatus. In particular, the com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple#setRollbackOnly method directly calls com.arjuna.ats.arjuna.coordinator.BasicAction#preventCommit, which, without lock or atomicity, both reads and modifies actionStatus. This will result in a poorly-defined outcome when threads concurrently call setRollbackOnly() and, say, rollback().

      Other methods access actionStatus without regard to concurrently protection, including:

      • com.arjuna.ats.arjuna.coordinator.BasicAction#save_state
      • com.arjuna.ats.arjuna.coordinator.BasicAction#toString
      • com.arjuna.ats.arjuna.coordinator.BasicAction#restore_state

      Some methods appear to be assuming that other methods will acquire the instance monitor before calling them; as a matter of best practice, such methods should have assert Thread.holdsLock(this); at their beginning point.

      Other fields in the class should also be analyzed for unsafe access.

              rhn-engineering-mmusgrov Michael Musgrove
              dlloyd@redhat.com David Lloyd
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

                Created:
                Updated:
                Resolved: