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

[Tom Jenkinson]

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/632161#632161

--------------------------------------------------------------
Hi,

The implementation for this issue (registered as  https://issues.jboss.org/browse/JBTM-916 https://issues.jboss.org/browse/JBTM-916) has been put back to svn.

The implementation I went for structures the XID as follows:

int formatId = // new sequential number
byte[] globalTransactionId = // Uid + Node name of transaction originator
byte[] branchQualifier = // Uid + Node name of subordinate + Node name of subordinates parent + EIS name

In order to fit the node names in the space available they have had to be encoded as integers (rather than strings as they used to be). I appreciate from Davids points above that this will add configuration complexity as nodes must be assigned a unique transaction manager identifier and remoting string but at the moment I can't really see any other way around this (I will elaborate further below on why the data is required).

I am happy for the node names to be changed back to Strings, but we have a space issue then which would definitely need addressing.

The space we are most constrained by is the bqual, it must contain a Uid is 28 bytes (this guarantees we have a globally unique identifier for any particular branch), it also needs two node identifiers which I opted for using integers (i.e. 2 x 4) , and an EIS name that can consume the remaining part of the bqual and is typically the JNDI name of the resource which can be up to 28 bytes. If there was someway to compress three reasonable length strings into the bqual (or put another way we can be certain that two string node names and an EIS resource name can be encoded into javax.transaction.xa.Xid.MAXBQUALSIZE - com.arjuna.ats.arjuna.common.Uid.UID_SIZE bytes [64 -28]) then it is a trivial change to revert node names back to Strings.

Now, onto the reasoning for why the data is required at each point, before this I will clarify one piece of terminology:
orphan resource = a resource that has prepared and stored an XID but where the transaction manager did not have chance to write out a record of the XAResource before it crashed
A> global transaction ID - This definitely needs a UID for uniqueness, it also needs the node name encoding in it so that orphaned (JTA) resources can be rolled back.
B> branch qualifier - Each RM needs a identifier unique within the global transaction ID, it also needs the subordinate node name to ensure the transport is able to filter out Xids returned from the XATerminator recover method so that different root transaction managers don't try to recover each others transactions. It also needs a subordinates parent node name for a similar reasoning to the node name encoded into the gtrid, i.e. to ensure that when a recovery manager for the suboridnate starts up it can detect XA resources of a subordinate transaction where the XAResource prepared and stored the Xid but the subordinate transaction itself failed to prepare.

In terms of the bqual, it is not an absolutely vital component to store the parent node name. If you look at   https://svn.jboss.org/repos/labs/labs/jbosstm/branches/JBOSSTS_4_15_0_Final/atsintegration/tests/classes/com/arjuna/ats/jta/distributed/server/impl/ServerImpl.java https://svn.jboss.org/repos/labs/labs/jbosstm/branches/JBOSSTS_4_15_0_Final/atsintegration/tests/classes/com/arjuna/ats/jta/distributed/server/impl/ServerImpl.java -r 37583 you can see that as I have a single ProxyXAResource per Xid and not a single XAR for all Xids I am able to filter the Xids returned from XATerminator.recover on format ID and gtrid alone. This is because I know that per subordinate transaction there should only ever be one single proxy XA resource talking to it (see the design discussion I am about to create for more details on this). Providing the parent node name though allows you to create a proxy XA resource that can recover all XIDs for a subordinate in one go, rather than calling recover multiple times.

Hopefully this clarifies the motivation why the Xid has been encoded as it has and why I have had to move to integers for node names.

Tom
--------------------------------------------------------------

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

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/20111017/4b584c9c/attachment.html