Remote Tx Inflow: Proxying a transaction as an XAResource issue

[tomjenkinson]

I have started to implement (https://svn.jboss.org/repos/labs/labs/jbosstm/branches/JBOSSTS_4_15_0_Final_JBTM-895) the planned approach to facilitiate remoting being able to flow a transaction between servers but have come up against the following issue.

Basically, the plan is to get the transport to register an javax.transaction.xa.XAResource that can intercept calls to javax.transaction.Transaction lifecycle management calls such as commit/rollback and relay those over to the remote transaction manager.

This is all looking good until you realise that the signature for XAResource permits fewer exception types than the corresponding Transaction signature, resulting in a loss of prescision in the proxy code. As such as I tried to map the javax.transaction.Transaction exception types for commit/rollback using the available XA error codes.

Just wondered if people can see any issues with the mappings I have done or can spot more appropriate ones:

try {

remoteManager.commit(xid);

} catch (SecurityException e) {

// This should never happen really as the root TM should have detected this

throw new XAException(XAException.XAER_OUTSIDE);

} catch (RollbackException e) {

throw new XAException(XAException.XA_RBPROTO);

} catch (HeuristicMixedException e) {

throw new XAException(XAException.XA_HEURMIX);

} catch (HeuristicRollbackException e) {

throw new XAException(XAException.XA_HEURRB);

} catch (SystemException e) {

throw new XAException(XAException.XAER_PROTO);

}

try {

remoteManager.rollback(xid);

} catch (IllegalStateException e) {

throw new XAException(XAException.XAER_NOTA);

} catch (SystemException e) {

throw new XAException(XAException.XAER_PROTO);

}

Comments/suggestions?

[dmlloyd]

I agree that the question of exception mapping is very relevant.  I just want to point out that we are not planning on exposing a remote interface sort of view for TransactionManager.  It's actually happening over the wire.  So implementation-wise we'll probably ship over a one-byte code or something which corresponds to the exception thrown.  Then on the client side we'd map the code to the XAResource exception.  Since the XAResource side is the lossy side we'd ship over the maximally detailed error code from the server and then pare it down on the client, to future-proof against future, better client APIs.

In other words, the try/catch blocks you illustrate won't actually literally exist anywhere.

[tomjenkinson]

Hi David,

I appreciate that totally, but the issue will still arise even if its more a case of:

sendRemotingRequest("commit");

byte response = receiveRemotingResponse();

switch (response) {

     case 3:

          throw new XAException(XAException.XAER_PROTO);

/// etc

}

[dmlloyd]

Right, the question is definitely relevant.

[marklittle]

Don't duplicate work that's already done and make sure new work is consistent with work that's already done . So check out what we're doing within subordinate implementations, which already have this mapping problem. Look at the JTAX and JTS implementations as examples.

[tomjenkinson]

Will do, but this issue is because we are relaying transaction completion information via an XAResource and so losing some precision, I guess JTS doesn't need to do that? Will check though...

[tomjenkinson]

Following Marks excellent advice, and after finally getting a prototype implemented I discovered that this very issue is already resolved for us by JCA.

You can see the recommended approach in: https://svn.jboss.org/repos/labs/labs/jbosstm/branches/JBOSSTS_4_15_0_Final/atsintegration/tests/classes/com/arjuna/ats/jta/distributed/server/impl/ServerImpl.java -r 37580

You can see the implementations of commit and rollback that do XAException acceptable mappings at: https://svn.jboss.org/repos/labs/labs/jbosstm/branches/JBOSSTS_4_15_0_Final/ArjunaJTA/jta/classes/com/arjuna/ats/internal/jta/transaction/arjunacore/jca/XATerminatorImple.java -r 37579