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

EIS can't recover inflowed transaction when heuristic outcome happens and tooling is used to reset the participant to prepared

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed (View Workflow)
    • Priority: Critical
    • Resolution: Done
    • Affects Version/s: 5.3.3.Final
    • Fix Version/s: 5.3.5.Final
    • Component/s: JTA
    • Labels:
      None
    • Steps to Reproduce:
      Hide

      Crashrecovery testsuite could be used for reproducing the issue

      git clone http://git.app.eng.bos.redhat.com/git/jbossqe-eap-tests-transactions.git
      mvn clean verify -am -pl jbossts -DfailIfNoTests=false -fn -Djbossts.noJTS -Dtest=JcaInflowTransactionTestCase#rmerrWithRecovery
      
      Show
      Crashrecovery testsuite could be used for reproducing the issue git clone http: //git.app.eng.bos.redhat.com/git/jbossqe-eap-tests-transactions.git mvn clean verify -am -pl jbossts -DfailIfNoTests= false -fn -Djbossts.noJTS -Dtest=JcaInflowTransactionTestCase#rmerrWithRecovery

      Description

      For "a normal" transaction which is started and managed by transaction manager heuristic state is expected to be solved this way

      1. prepare phase successfully finishes, participant make a heuristic decision (ie. rollbacks) which causes that TM receives a XAException with error code as e.g. XA_RMERR or XA_HEURRB.
      2. transaction is marked to have heuristic result and manual intervention is necessary
      3. user calls recover for participant at such state and its state is changed to prepared
      4. replay of commit is called for the participant which causes to get commit called once again for the XAResource and participant record is removed from TM object store

      This workflow does not work for inflow transaction where EIS is expected to order the TM to commit (as TM stands in position of subordinate transaction manager). The expected procedure should be

      1. EIS propagates EIS TX to Narayana
      2. enlisting XAR in Narayana subordinate TX
      3. committing EIS TX
        1. It commits Narayana subordinate TX
      4. XAR in Narayana TX returns RMERR
      5. Narayana returns XA_HEURMIX
      6. calling the Narayana tooling op recover to move the heuristic back to prepared
      7. EIS should not forget its TX where Narayana TX is a subordinate as we returned a heursitic so its not allowed to forget it yet
      8. EIS should call Narayana via XATerminator::recover()
        1. getting back an Xid that matches to Narayana subordinate TX
      9. EIS should try again to complete this Xid it sees fit according to its own recovery log, e.g. e.g. call XATerminator::commit(xid)
        (in the real world once an XAR had rolled back it would be unlikely to ever be able to commit again so it would be a bit synthetic to allow it commit so it would be up to you how you decide to complete the TX)

      The issue is that recover operation returns the state of participant to prepared but EIS commit call ((XATerminator.commit) does cause XAResource.commit being invoked and participant log being removed from the TM object store.

        Gliffy Diagrams

          Attachments

            Issue Links

              Activity

                People

                • Assignee:
                  tomjenkinson Thomas Jenkinson
                  Reporter:
                  ochaloup Ondrej Chaloupka
                • Votes:
                  0 Vote for this issue
                  Watchers:
                  2 Start watching this issue

                  Dates

                  • Created:
                    Updated:
                    Resolved: