[jboss-dev-forums] [JBoss Transactions Development] - Re: Remote Txn Inflow: Synchronizations
David Lloyd [http://community.jboss.org/people/dmlloyd] created the discussion
"Re: Remote Txn Inflow: Synchronizations"
To view the discussion, visit: http://community.jboss.org/message/629604#629604
--------------------------------------------------------------
Tom Jenkinson wrote:
> 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.
Yes, but it's public in that module. Whether or not an API is public is
determined by wether it's public, not by whether it's being used in a particular
codebase.
Tom Jenkinson wrote:
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.
There's just no reason to decouple this
code, unless you really want to do the extra work. From our perspective, if we used
SubordinationManager directly, and then you made some incompatible change, we'd simply
change our usage of it accordingly for the version of AS that included the updated TS;
it's really not necessary to create an abstraction for our benefit. The best API is
not the one with the most abstractions, but the fewest - less code for everyone to
maintain, and simpler contracts, mean a win for everyone in most cases. (I could go on
about API design all day...)
I just want to make it absolutely, perfectly clear that this is not a requirement as far
as we're concerned, we consider it to be much more important to hit the EAP 6 target
than to have an abstraction layer over code which is already public (in the concrete Java
sense, not in the socio-political sense you are alluding to). It is up to you to decide
if it is worth it.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/629604#629604]
Start a new discussion in JBoss Transactions Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&...]
Attachments:
- attachment.html (text/html — 6.9 KB)