11 Replies Latest reply on Jan 24, 2007 3:02 AM by Mark Little

    Problem recovering inbound transaction

    Stephen Burdeau Newbie

      I have a custom JCA 1.5 compliant resource adapter (called DTPRA) that I am attempting to test with JBoss Application Server 4.0.5 and JBoss Transactions 4.2.2. DTPRA has already been successfully tested with JBoss 4.0.2 (without recovery) and with BEA WebLogic Server 9.0 and IBM WebSphere Application Server 6.0.1 (both with recovery).

      For this scenario, I am using the JBoss Application Server "all" config with the distributed JTA configured.

      I ran a test with an inbound transaction to DTPRA using JCA 1.5 transaction inflow. This worked fine with no errors or unexpected warnings.

      I ran the same test again with a sleep in DTPRA code so I could test recovery.

      Here is a high-level summary of what is happened:
      1) DTPRA generated an XID and called XATerminator.prepare with this XID. XATerminator.prepare returned XA_OK, as expected.
      2) Everyone involved in the transaction is successfully logged.
      3) Before calling XATerminator.commit, I killed the Java process running JBoss.
      4) I restarted JBoss.
      5) DTPRA called XATerminator.recover and it returned one XID. However, the XID did not match the XID that DTPRA supplied earlier on the XATerminator.prepare call.
      6) Later, DTPRA called XATerminator.commit with the the same XID supplied in step 1. This failed with an XAException with an errorCode of XAER_INVAL.

      In particular, DTPRA called XATerminator.prepare and XATerminator.commit with the following XID:
      where the first value is the format ID, the second value is the global transaction ID, and the third value is the branch qualifier. All three values are hexadecimal values, not printable ASCII characters.

      The XID returned from XATerminator.recover is the following:
      0x312d2d33666330326139663a3534623a34353736653366373a3935, 0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000

      That is, the global transaction ID is the ASCII string:

      So, I have the following issues:
      A) I expected the XID returned from XATerminator.recover to match the XID I supplied earlier to XATerminator.prepare.
      B) I expected the call to XATerminator.commit during recovery to succeed.