How does this look as an interface to drive the required behaviour?
I would assume you would acquire a singleton instance of this through a getter on the impl, e.g.
JTADistributionManager manager = JTADistributionsManagerImpl.getJTADistributionManager()
public interface JTADistributionManager {
// TRANSACTION ASSOCIATION MANAGEMENT
void start(Xid xid, long timeout) // This should be the absolute time you want the transaction to timeout
void resume(Xid xid) // TO BE CALLED WHEN YOU WANT TO RESUME THE TRANSACTION AT THIS NODE
void suspend(Xid xid) // TO BE CALLED WHEN YOU WANT TO SUSPEND THE TRANSACTION AT THIS NODE
/// TRANSACTION LIFECYCLE MANAGEMENT
int prepare(Xid xid) throws XAException;
void commit(Xid xid) throws XAException;
void rollback(Xid xid) throws XAException;
void forget(Xid xid)
Xid[] recover(int flag)
// SYNCHRONIZATION CONTROL
void beforeCompletion(Xid xid);
void afterCompletion(Xid xid, int status);
}
NOTES:
Regarding the timeout, I figured the transport would converted this to an absolute time? I can only really see it working with an absolute time and clocks in sync, then when we add it to the reaper we can calculate the remaining time. I am interested to know in the original question some of Davids concerns regarding timeout.
Assumptions:
1. Every time remoting invokes a remote application server it must do the following two things:
a. If not already done so, create a proxy Synchronization object and register it with the transaction - distributed JTA interposed synchronizations are not supported in the initial version. This will invoke the beforeCompletion and afterCompletion methods on the remote JTADistributionManager
b. f not already done so, create a proxy XAResource object and register it with the transaction, this is responsible for sending the subordinate transaction managers transaction lifecycle messages prepare, commit, rollback, forget, recover, setTransactionTimeout
c. On the remote side, it needs to call either start/resume dependent on whether remoting detects it has sent the transaction to this server before
d. After remoting detects the interaction is complete, it can call end on the JTADistributionManager
2. As we have no way to communicate back up the tree, I have assumed that only the originating client can initiate completion of a transaction, this is consistent with the JTA spec 3.2.2 but will need documenting
3. In the case of failure afterCompletion may not be called
As yet unresolved is how to modify the Xid correctly in order that local recovery managers detect the indoubt transactions, watch this space, but this is being tackled, David mentioned an approach on the Synchronizations thread that may assist: http://community.jboss.org/thread/172869?tstart=0
If you are happy with the proposed interface I will update: https://issues.jboss.org/browse/JBTM-895