David Lloyd wrote:
Tom Jenkinson wrote:
I don't think we should expose SubordinationManager directly as we don't necessarily want to make that a public API. As such we should probably expose a new API specific to the job, I have posted this on the other thread so people watching that thread only will get the update.
Well, that API is already public so I think that ship has sailed. That said I'd hate to pile more work on you guys in the name of Yet Another Abstraction (gods know we have enough of those already).
Sorry, I must not have the code in my workspace that uses SubordinationManager outside of jbosstm? Can you point me at the code that uses it directly then I can take a look to see? I have JCA, AS and jbosstm branch in a workspace and grepped it for text string "SubordinationManager" but the only references I found where in jbosstm.
The abstraction I am proposing is not going to be heavy, and it will probably be useful so that we know what was added for this work and can potentially vary SubordinationManager independent of this API. I was just going to put it in the atsintegration module. I would expect your proxy endpoints to do things like:
JTADistributionManager.getDistributionManager().commit(XID)
Or whatever, this would call code I would provide that looks a bit like this:
public void commit (Xid xid) throws XAException
SubordinateTransaction tx = SubordinationManager.getTransactionImporter().getImportedTransaction(xid).commit();
That said, if you can point me at code "in the wild" that uses SubordinationManager directly (as I say, it could be a module I don't have checked out) I am happy to review the proposed solution and use SubordinationManager as a public API and extend that accordingly. For instance though, access to this API in JCA is mediated through the XATerminatorImple.