Because the TransactionManager has no way to register a XAResource manager, so that it can enlist XAResources in future Transactions.
The only way to solve this problem is to wrap the handle of the interested service interface.
Each method on the interface does the following:
- Check if a tx is present
- Figure out if the handle for this tx
- If not already participating enlist its XAResource using Transaction.enlist(XAResource)
- Registers a callback to enable cleanup using Transaction.registerSynchronization(Synchronization).
Does this seem like a reasonable strategy ?
It’s a reasonable first draft, but there are some subtleties to watch out for. Getting the corner cases right yourself is hard – you may be better off writing a resource adaptor for your code and having a JCA handle the transaction plumbing, which is what most database and message queue drivers do.
Just because a tx context is present, that does not mean you can enlist with the tx. In particular the spec requires enlistResource to throw RollbackException if the tx is marked rollback only.
Just because the context is present and the tx has a valid state at the time you check it, that does not mean it remains present or valid throughout the lifetime of the method call. You can get race conditions in which the TM calls rollback on the resource whilst your business logic is still running.
The relationship between XAResource object instances, instances of the service interface and transactions is not particularly elegant due to XA’s C heritage. In connection oriented APIs like JDBC it is normally one XAResource per Connection, with that XAResource instance potentially managing multiple tx contexts. For connectionless APIs you can use other patterns which may be simpler.
The Synchronization is not necessary. Nor is it necessarily desirable as Synchronizations are volatile so your cleanup won’t get called in crash recovery situations. Better to clean up on commit/rollback in non-heuristic cases.