[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/629306#629306 -------------------------------------------------------------- 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)? 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. 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. 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&...]