Problem recovering inbound transaction

[burdeasa]

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:
0x44545031,
0xa08006092b81403f8176768f520000820400757e21,
0x06092b81403f815561ae73
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:
131075,
0x312d2d33666330326139663a3534623a34353736653366373a3935, 0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000

That is, the global transaction ID is the ASCII string:
1--3fc02a9f_54b_4576e3f7_95


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.

[weston.price]

Finally an interesting case!

I am going to have to throw together a test case against 4.0.5. Also, to clarify, are you using the WorkManager contract as way to import the Xid?

[burdeasa]

Yes, a Work object references an ExecutionContext object which contains the XID which DTPRA generated.

In case it helps:
BTW, a coworker indicated that he performed a similar test with similar results with a different resource adapter. However, in his case, he had three in-doubt transactions at the time of recovery, and the XATerminator.recover returned an XID array with three items. The first XID was a similar format to the one I saw (with format ID 131075). The other two entries in the array were null.

Also, I can readily reproduce my scenario if you want me to try with different config settings or trace options.

Thanks for looking at this.

[burdeasa]

Is there any update on this issue?

I don't want to nag; I know its the holidays!

Just wondering ...

[peterj]

Is there a JIRA opened for this issue? I couldn't find one. If I don't hear back, I will open one for both the 4.2.3 and 4.3 releases.

[marklittle]

I believe Weston was looking into it. Nothing in JBTM JIRA, but I haven't checked JCA. May be an idea to see what Weston has to say when he returns from vacation.

[peterj]

I create issue http://jira.jboss.org/jira/browse/JBTM-187

[marklittle]

OK. I've removed the dependency on a 4.2.3 fix. We'll take a look asap, but 4.2.3 may be too short notice.

[peterj]

Fine by me, as long as there is a JBossAS 4.0.x-compliant release that it will go into (in other words, will there be a 4.2.4?). That is why I warned you about which releases I would attach it to in my earlier post.

[marklittle]

If it's a bug then we'll release an MP for 4.2.3 (assuming it doesn't get in there in time).

[weston.price]

Crap...Sorry guys, I completely forgot about this one...what did I miss?

Sigh...I know, I know..I'm a loser :-(

[marklittle]

No problem. Was an issue at our side, which should be fixed soon.