[jboss-dev-forums] [JBoss Transactions Development] - Re: Remote Txn Inflow: Synchronizations

[David Lloyd]

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&containerType=14&container=2041]

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jboss-dev-forums/attachments/20110930/aa2d8120/attachment.html