[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/629306#629306

--------------------------------------------------------------
> Tom Jenkinson wrote:
> 
> Hi David,
> 
> It looks like we would need at least two additional functions to XATerminator, in the diagram referred to as "XA Terminator enhancement":
> a. A before completion method
> b. An after completion method
> 
Just a quick note here that we can use other classes than XATerminator; there is no need for this particular code (i.e. the EJB server transaction inflow code) to be loosely coupled from the transaction manager, so we should implement the most direct and most correct solution, which probably means just bypassing XATerminator and using the APIs consumed by it.  In fact we are already planning on doing so because EJB invocation isn't done with "Work" which is presently the way that tasks are executed via JBossXATerminator instances.

But yeah, adding these methods (and a protocol message to convey them) is what I mean by "a way to inflow these requests".  The question is, do we support interposed sync as well, which (as far as I understand) would mean two phases of each completion method (one to fire off non-interposed and one to fire off interposed)?

> Tom Jenkinson wrote:
> 
> In this picture, I would expect the transport to register a "proxy synchronization" for each subordinate transaction manager that the transaction flows to using the standard Transaction::registerSynchronization mechanism. This proxy would need to be implemented by the (in this case remoting) transport and know how to invoke the remote (new) beforeCompletion/afterCompletion methods on our "enhanced" XATerminator class.
> 
> Does that sound reasonable?
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.

> Tom Jenkinson wrote:
> 
> Note, I am also thinking that a similar method will need to be employed to ship the Transaction related functions around, i.e. the transport will be responsible for registering an XAResource with the transaction which is responsible for performing transport layer shipping of these messages to the subordinate transaction manager.
Yeah the current mechanism involves getting an XID how you describe (via the client registering itself as an XAResource) and attaching the resultant XID to all requests in that transaction; the server-side interceptor will be responsible for mapping the XID to a Transaction to resume for the duration of the request.  I think we probably should use the same SubordinationManager-based scheme for looking up the transaction though.

> Tom Jenkinson wrote:
> 
> The main issue I am still getting my head around is recovery of this system and in particular a way of altering the XID so that local transaction managers can create branches for their XAResources. JCA does not permit this so it still needs a think·
> 
> Tom
Yeah this is the #1 issue.  I think the only real option is a new XID format.

Since the node relationship is hierarchical, it makes sense to me that the bqual should also be hierarchical.  We could use a single integer value to represent the branch relative to a particular node, and keep a local mapping of value to subnode identification.  This would be enough information to recover, as long as the node connections are all active.

Using fixed-length integers, 64 bytes limits things considerably.  Even if you didn't need any bytes for recording existing information that gives you at most 64 levels of 256 resources per level.

You could however use integer packing to make more room; in such a scheme, the bqual bits which identify the node would still be an integer sequence but would work like this:

* Values 0000-0111 (0-7): resources 0-7, length is 4 bits
* Values 1000 0000-1011 1111 (0x80-0xBF): resources 8-71, length is 8 bits
* Values 1100 0000 0000-1101 1111 1111 (0xC00-0xDFF): resources 72-583, length is 12 bits
* etc.

You can tell how many bits to consume by the number of leading high-order bits.  Such a scheme can be expanded indefinitely, and supports both many levels with few resources and few levels with many resources.

I assume that as part of recovery, we will have to somehow recreate all of our XAResources?  Or does the TM serialize them or something?
--------------------------------------------------------------

Reply to this message by going to Community
[http://community.jboss.org/message/629306#629306]

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/20110929/4920a1ff/attachment.html