Mmusgrov I'm not sure i understand your answer, let me answer in two parts. "mmusgrov" wrote : This is true in the case of the X/Open Distributed Transaction Processing specifications. Are you saying that the solution proposed by Mark wouldn't work in the case of XA transactions (2PC)? I have read the general paragraphs and the ones that talk about asynchronicity in http://www.opengroup.org/onlinepubs/009680699/toc.pdf, is this the specification you're talking about? I don't see where it says this, then again i didn't understand everything. It does say this: anonymous wrote : 3.3 Association of Threads with Transaction Branches | Several threads may participate in a single transaction branch, some more than once. But does it imply that conversely Several threads may not participate in several transaction branches. Maybe you were thinking of something more explicit elsewhere? "mmusgrov" wrote : The problem with a client starting a transaction and then making an asynchronous call to a remote server is that | the client may call commit whilst the server is still trying to do transactional work. | To cater for this scenario X/Open disallows transaction propagation on asynchronous requests. | This is in contrast to synchronous or conversational requests in which case context propagation is allowed. I don't see why 2PC makes Checked Transactions semantics not applicable: In the solution explained in http://www.cs.ncl.ac.uk/publications/inproceedings/papers/598.pdf, the "root" transaction can commit only after all its "daughter threads" have sent it a completion message. If so, then wouldn't the same solution work in XA just by replacing the global commit (executed on completion of all daughter threads) by a prepare? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4255877#... Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&a...