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

Transaction .equals() methods do not comply with specification

    XMLWordPrintable

Details

    • Bug
    • Resolution: Done
    • Blocker
    • 5.5.2.Final
    • None
    • JTA
    • None
    • Low

    Description

      The JTA specification has this to say about Transaction.equals():

      The transaction manager must implement the Transaction object's equals method to allow comparison between the target object and another Transaction object. The equals method should return true if the target object and the parameter object both refer to the same global transaction.

      For example, the application server may need to compare two Transaction objects when trying to reuse a resource that is already enlisted with a transaction. This can be done using the equals method.

      Transaction txObj = TransactionManager.getTransaction();
      Transaction someOtherTxObj = ..
      ..
      boolean isSame = txObj.equals(someOtherTxObj);
      

      In addition, the transaction manager must implement the Transaction object's hashCode method so that if two Transaction objects are equal, they have the same hash code. However, the converse is not necessarily true. Two Transaction objects with the same hash code are not necessarily equal.

      There are several transaction implementation classes in Narayana including:

      • com.arjuna.ats.internal.jta.transaction.arjunacore.subordinate.jca.TransactionImple
      • com.arjuna.ats.internal.jta.transaction.arjunacore.subordinate.TransactionImple
      • com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple

      Sometimes it comes to pass that, for whatever reason, importing a transaction might return a transaction instance of a different type than what was previously returned. In this case the flaw in the equals method is clear: it compares the types for effective equality before it compares the UID, causing two transactions of different types which refer to the same global transaction to be non-equal, which causes integrity checks in the remote JTA code to fail.

      I'll provide a PR that fixes the issue which you can use if you want.

      Attachments

        Issue Links

          Activity

            People

              dlloyd@redhat.com David Lloyd
              dlloyd@redhat.com David Lloyd
              Votes:
              0 Vote for this issue
              Watchers:
              5 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: