[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/629583#629583
--------------------------------------------------------------
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
[http://community.jboss.org/message/629583#629583]
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 — 5.7 KB)