JBoss Community

Re: Remote Txn Inflow: Synchronizations

created by David Lloyd in JBoss Transactions Development - View the full discussion

Tom Jenkinson wrote:

 

David Lloyd wrote:

 

Yeah that should be fine, just let me know what the method hooks will be.  I'm also fine with using SubordinationManager directly, or providing an alternative extended version of com.arjuna.ats.internal.jta.transaction.arjunacore.jca.XATerminatorImple, or whatever is easiest for you guys.  In particular, at a protocol level it does us no good to have all the execptions mapped to XAException because we'll just have to decode it again and send it over the wire; it just costs an extra, useless transaction wrapping.

 

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).

 

Here's the deal with public API support.

 

On the client side, our jboss-ejb-client JAR is expected to be forwards compatible from now until pretty much the end of time.  That means, no using non-standard transaction APIs, period - the "outflow" of the transaction is done purely via the TransactionManager and TransactionSynchronizationRegistry implementations and via XAResource, and I don't see this changing anytime soon.  The client cannot do anything that cannot be done with these interfaces.

 

The server side (which needs to consume this API) is a completely different matter.  The wire protocol is our point of compatibility; everything else is tightly coupled to the AS release.  The classes which inflow the transaction into the server can be as proprietary and/or expedient as we need them to be - and given the late hour, it's not the time for any grand new abstraction layers.  We already have tight coupling with JBossTS - allowing pluggable transaction managers in AS 7 isn't something I see happening (and if it does, that would be the time to revisit abstraction layers).

 

So what I'm saying is, I'd hate to see you guys dragged into a lot of unnecessary work when 95% of the required API already exists.

Reply to this message by going to Community

Start a new discussion in JBoss Transactions Development at Community