Are you referring to the TrCoreProgrammersGuide pdf? I think so (was probably renamed) but just to be sure. I did find something of interest in it: "TrCoreProgrammersGuide.pdf page33 (Checking transactions)" wrote : | When a thread attempts to terminate the transaction and there are active threads within it, the system will invoke the check method on the transaction’s CheckedAction object. | The parameters to the check method are: | - isCommit: indicates whether the transaction is in the process of committing or rolling back. | - actUid: the transaction identifier. | - list: a list of all of the threads currently marked as active within this transaction. | When check returns, the transaction termination will continue. Obviously the state of the transaction at this point may be different from that when check was called, e.g., the transaction may subsequently have been committed. As i thought, the check method is passed a list of the active threads. If i'm not mistaken, i would just need to implement a BlockingCheckedAction, that calls join() on all those threads, and use it for the global transaction. To sum it up: 1/ Launch the server with -Dcom.arjuna.ats.jts.checkedTransactions=YES to enable checked transactions 2/ Implement BlockingCheckedAction that does: for (Thread t: list) { t.join() } 3/ Just after the global transaction has started i would need to do Current current = OTSManager.get_current(). | current.setCheckedAction ( new BlockingCheckedAction() ); I thought of a simple unit test to verify the correctness of the transactional behaviour. Do you think this would work? I prefer asking before i start spending time integrating another TransactionManager in Spring. 1/ UnitTest (UT) calls transactional service void updateXY ( int X , int Y , boolean failOnUpdatingY ) synchronously 2/ The global transaction is initiated and updateXY updates X 3/ updateXY then calls transactional service updateY ( int Y , boolean failOnUpdatingY ) asynchronously 4/ updateY executes within the same global transaction; if (failOnUpdatingY) a RuntimeException is thrown, which must rollback the global transaction 5/ UT sleeps for a second, by then the transaction should have been committed or rolled back 6/ UT calls getX and getY 7/ Verifications: Case ! failOnUpdatingY: X and Y should have their new values because the global transaction has been committed Case failOnUpdatingY: X and Y should have their old values because the global transaction has been rolled back View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4256543#... Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&a...