[jboss-dev-forums] [JBoss Transactions Development] - Re: Remote txinflow: XID changes

Tom Jenkinson [http://community.jboss.org/people/tomjenkinson] created the discussion "Re: Remote txinflow: XID changes" To view the discussion, visit: http://community.jboss.org/message/633307#633307 -------------------------------------------------------------- Just to round off the discussion: Basically, I determined that the subordinate node name is not strictly a "node identifier" in the same sense as we are requiring it for a JTA gtrid value (which must be unique per object store). Instead it need only be unique per propagated transaction and the server does not need it to be the same value for different transactions flowed through the it, nor indeed must the value be globally unique (i.e. different servers can reuse the same id so long as it is not used by a different server within the scope of the same transaction). All that that does need to happen is that the transport dynamically assign a unique integer for each node participating in a transaction, e.g. a counter starting at 1 and a recoverable mapping file be stored *by the transport* so that for any given transaction a server (keyed by the traditional String node identifier) knows what its own (now dynamic) "subordinate node name" was for the transaction, thereby assisting it with recovery. To that end I have only had to change: XID { int:formatId byte[]:gtrid { UID:sequence, String:nodeName } byte[]:bqual {UID:sequence, String:EIS name } } To: XID { int:formatId byte[]:gtrid { UID:sequence, String:nodeName } byte[]:bqual {UID:sequence, int:subordinateNodeName, String:EIS name } } (i.e. added that single integer into the bqual). It does mean the transport needs to work a little harder to maintain this mapping and dynamically track available subordinate node names for each transaction flow but has solved the issue with dealing with dynamically allocated subordinate node names. It also means that setNodeIdentifier is totally compatible with previous versions of AS (i.e. any String is allowed for a node identifier, not just an Integer encoded as a String) and has therefore further minimized the changeset required from the core JTA side so is safer from an existing functionality point of view. Thanks to everyone for their suggestions on this, also, clearly the restriction about the (now reverted to String) node identifier being unique within the domain is all the more more vital. For those tracking this discussion, the reason the parent node name is no longer required is because: a> only one proxy can be added for any particular transaction at any particular server and b> the proxy xa resource transport addition must track transactions in flight for each server so therefore it takes the place of this particular value For those who are wondering about the subordinate node name is now able to be dynamic, the reason is the we rely on the transport must storing this data now rather than reading it from one of our configuration files. Essentially the requirements of the solution are the same as they have always been, it is just that a little bit more data is required to be stored by the transport than was the case before. I do have examples and tests for all of this:  https://svn.jboss.org/repos/labs/labs/jbosstm/branches/JBOSSTS_4_15_0_Fin... https://svn.jboss.org/repos/labs/labs/jbosstm/branches/JBOSSTS_4_15_0_Fin... and https://svn.jboss.org/repos/labs/labs/jbosstm/branches/JBOSSTS_4_15_0_Fin... https://svn.jboss.org/repos/labs/labs/jbosstm/branches/JBOSSTS_4_15_0_Fin.... In particular, the example should prove to be extremely useful when developing the transport required for this as it shows and describes the points where relevant transaction data must be reliably persisted. As I say, by reverting to a String node identifier, the solution is even closer to the original mechanism so therefore this new approach should have no impact on existing JTA/JCA work. The only difference now is that the space available to EIS namesis one byte shorter (from 36 to 35 bytes). -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/633307#633307] Start a new discussion in JBoss Transactions Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&...]