OK, JBTM-474 seems to have helped somewhat. There is still an issue with some of the JCA tests[1] that use the following cleanup code:

if (!TxUtils.isCompleted(tm))
{
tm.rollback();
fail("Tx was still active");
}

rollback is called, which is correct - it's needed to ensure thread disassociation. Note that the test is broken even for the JTA case, since there may be a complete tx associated to the thread and the rollback call is needed to disassociate it even if it's already rolled back. But in the JTS case since it can't determine the tx rolled back, rollback throws an exception rather than silently working as the JTA version does.

The issue here is that a timedout JTS tx is removed at the point it times out so thereafter its status cannot be determined. For some use cases (where the client and server are collocated) we could cache the outcome at the point the tx is removed, allowing getStatus and rollback|commit to behave more similarly to the JTA version.

But that won't work in distributed cases, since the tx is remote which means we either need it to hang around as long as a client has a handle on it (i.e. it's a distributed gc problem) or we need to notify all the clients of the outcome when it terminates (i.e. communication overhead). Neither of these appeal.

Thus the JCA test is going to have to change anyhow to cope with the distributed case.

It seems to me that what the test is really in interested in is: did the tx timeout as expected. It could either register a sync and use that to set a status flag, or rely on isActive() rather than !isCompleted. Either way it needs an exception handler around tm.rollback, since that call is going to throw an exception.

[1] org.jboss.test.jca.test.TxConnectionManagerUnitTestCase
methods testSynchronizationAfterCompletionTxTimeout
testGetManagedConnectionTimeoutTrackByTx
testGetManagedConnectionTimeout

So in the case of a commit from another thread the object hangs around rather than getting thrown away? Otherwise the translation is suspect...

I'm not arguing with the ORB's behavour, I'm arguing about the way the transaction service sat on top of the ORB translates that. If a client gets an OBJECT_NOT_EXIST it only knows the tx went away, not what state the tx was in. Assuming rollback is unreasonable - it may just as easily have committed via another thread or a different JVM.