Transaction bridging bug?

[kadlecp]

Hello,

I am JBossESB user and I am intergrating WS-Transaction into that project, including transaction bridging. I have checked out txBridge from http://anonsvn.labs.jboss.com/labs/jbosstm/workspace/jhalliday/txbridge

When I tested txBridge and my intergation, I could see that there are bad results in my database. If one participant failed, the results of other successful participant were commited into database.. which is bad. Firstly I thought that 2-phase commit does not work well, but the problem is somewhere else.....

There is log of txBridge demo

11:28:55,248 INFO [STDOUT] CLIENT: obtaining userTransaction...
11:28:55,251 INFO [STDOUT] CLIENT: starting the transaction...
11:28:55,267 INFO [STDOUT] CLIENT: transaction ID= AtomicTransactionIdentifier: urn:a000002:c0a0:47b40ed7:1c66
11:28:55,270 INFO [STDOUT] CLIENT: calling business Web Services...
11:28:55,403 INFO [JaxWSClientHeaderContextProcessor] getHeaders
11:28:55,411 INFO [JaxWSClientHeaderContextProcessor] handleOutbound
11:28:55,423 INFO [JaxWSServerHeaderContextProcessor] getHeaders
11:28:55,429 INFO [JaxWSServerHeaderContextProcessor] handleInbound
11:28:55,498 INFO [JaxWSServerHeaderContextProcessor] handleOutbound
11:28:55,503 INFO [JaxWSClientHeaderContextProcessor] handleInbound
11:28:55,507 INFO [STDOUT] CLIENT: bookingCount: 0
11:28:55,511 INFO [JaxWSClientHeaderContextProcessor] handleOutbound
11:28:55,517 INFO [JaxWSServerHeaderContextProcessor] handleInbound
11:28:55,523 INFO [JaxWSServerHeaderContextProcessor] handleOutbound
11:28:55,531 INFO [JaxWSClientHeaderContextProcessor] handleInbound
11:28:55,535 INFO [JaxWSClientHeaderContextProcessor] handleOutbound
11:28:55,544 INFO [JaxWSServerHeaderContextProcessor] handleInbound
11:28:55,548 INFO [JaxWSServerHeaderContextProcessor] handleOutbound
11:28:55,559 INFO [JaxWSClientHeaderContextProcessor] handleInbound
11:28:55,563 INFO [STDOUT] CLIENT: bookingCount: 2
11:28:55,565 INFO [STDOUT] CLIENT: calling commit on the transaction...
11:28:55,571 WARN [AbstractEntityManagerImpl] Transaction not available on beforeCompletionPhase: assuming valid
11:28:55,745 DEBUG [BridgeParticipantAT] prepare on Xid=< 131075, 28, 64, 1-a000002:c0a0:47b40ed7:1c69
 > returning Prepared
11:28:55,755 DEBUG [BridgeParticipantAT] commit on Xid=< 131075, 28, 64, 1-a000002:c0a0:47b40ed7:1c69
 > OK
11:28:55,771 INFO [STDOUT] done.

There is a line in the log

11:28:55,571 WARN [AbstractEntityManagerImpl] Transaction not available on beforeCompletionPhase: a
ssuming valid

This is logged by hibernate when prepare is received from coordinator. It means that hibernate cannot find JTA transaction on thread, so hibernate flushes all entities into database immediately. Look at the http://anonsvn.jboss.org/repos/hibernate/entitymanager/tags/v3_2_1_GA/src/java/org/hibernate/ejb/AbstractEntityManagerImpl.java
on the line 483, Synchronization object.

I think repair is easy, when org.jboss.txbridge.BridgeParticipantAT receives prepare, it should associate thread with JTA transaction. The code might look like

public Vote prepare() throws WrongStateException, SystemException
 {
 log.trace("prepare(Xid="+xid+")");

 try {

 TransactionImple tx = TxImporter.getImportedTransaction(xid);
 txManager.resume(tx);

 // XAResource.XA_OK, XAResource.XA_RDONLY or exception. if RDONLY, don't call commit
 int result = xaTerminator.prepare(xid);
 if(result == XAResource.XA_OK) {
 log.debug("prepare on Xid="+xid+" returning Prepared");
 return new Prepared();
 } else {
 log.debug("prepare on Xid="+xid+" returning ReadOnly");
 return new ReadOnly();
 }

 } catch(Exception e) {
 log.debug("prepare on Xid="+xid+" returning Aborted", e);
 return new Aborted();
 } finally {

 try {
 txManager.suspend();
 } catch (javax.transaction.SystemException e) {

 e.printStackTrace();
 }
 }

With that fix, commit is done when commit is received from coordinator, and not when prepare is received.

What do you think? Shall be methods org.jboss.txbridge.BridgeParticipantAT.commit and org.jboss.txbridge.BridgeParticipantAT fixed in similar way?

Thanks for comments
Pavel Kadlec

[kadlecp]

Another possible bug is bug in class com.arjuna.ats.internal.jta.transaction.arjunacore.jca.TxImporter. There is one field

private static HashMap _transactions = new HashMap()

TxImporter is used by com.arjuna.ats.internal.jta.transaction.arjunacore.jca.XATerminatorImple. The field is static and there can be more XATerminatorImple objects in JVM or there can more threads in one XATerminatorImple object. The access to that field is not synchronized.

Pavel

[kadlecp]

And another possible bug is leaking memory bug....
org.jboss.txbridge.TxBridgeManager should contain method similar to this one

 public synchronized static void disposeInboundBridge(String externalTxId) {

 log.trace("disposeInboundBridge()");

 Xid xid = txIdMappings.remove(externalTxId);
 if (xid == null) {
 log.error("inconsistency: null jta xid");
 return;
 }

 InboundBridge inboundBridge = inboundBridgeMappings.remove(xid);

 if (inboundBridge == null) {
 log.error("inconsistency: null inbound bridge");
 return;
 }

 try {

 inboundBridge.stop();
 } catch (Exception e) {
 e.printStackTrace();
 }
 }

In my opinion method similar to method above should be called by BridgeParticipantAT when participant commits or rolls back. Somebody must dispose InboundBridge from maps in TxManagerBridge....

Pavel

[marklittle]

If you think there are errors, please create JIRAs and link in the forum entries. Thanks.

[kadlecp]

There is no Transaction Bridging project nor component in JIRA. Transaction Bridging is not versioned and is not included in JBoss TS releases. What project and component shall I publish transaction bridging bugs?

[marklittle]

Don't assign a component for now. We have to determine whether (and when) a bridging component will be added. But I'd prefer not to lose any issues in the meantime.

[kadlecp]

JIRAs created

http://jira.jboss.com/jira/browse/JBTM-326
http://jira.jboss.com/jira/browse/JBTM-327
http://jira.jboss.com/jira/browse/JBTM-328
http://jira.jboss.com/jira/browse/JBTM-329

[jhalliday]

Thanks Pavel. The bridge will need a substantial rewrite to deal with crash recovery and multiple servers. I'll fix the issues if any of the relevant code survives that process.

[kadlecp]

OK, before you rewrite the txBridge, I will use the old one with my fixes. I hope that it will be enough for my purposes. I am in the middle of testing, especially bad scenarios.

Pavel