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

Tom Jenkinson do-not-reply at jboss.com
Tue Oct 18 08:47:08 EDT 2011


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

--------------------------------------------------------------
Hi Mark,

In terms of raw XID manipulation:

I have ensured that in the case where we have none-distributed JTA the cost of this is zero (well, an initial check when generating the first XID has to compare a boolean to see if this is a subordinate).

In the case of existing JCA code there are a couple of further boolean checks when resolving existing SubordinateTransactions to check if the inflowed XID formatID is equal to one of ours, if false, do old comparison, if true do new comparison (which actually scores a hit by comparing gtrid only so that should be somewhat faster than comparing gtrid and bqual).

So essentially, the current system should remain as performant as it was. The distributed JTA case I have not performance tested as it is new functionality with nothing to compare against, though as the node identifiers are now integers I suspect encoding an XID will be more efficient than encoding an older XID.

In terms of architecural principal:
My tests for this simulate distribution via classloader separation. When David is able to consume the TS work, we can see what the cost of the distributed JTA vs JTS is "in real life". That said, I have placed a restriction that the graph of proxy XA resources must not contain loops (working with this is demonstrated in my example). This will ensure that transaction completion is efficient as you don't loop around the same nodes during completion, e.g. a transaction that flows through nodes 1,2,3,3,1,3,1,3 would get automatically merged (as the transport knows not to add completion links for nodes that are already connected in this transaction) and therefore gets ordered as 1,2,3 (though unfortunately not 1,2 and 1,3 which would be more efficient, but as the link from 2,3 is created before the link from 1,3 there is nothing we can do).

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

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

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/20111018/080299d0/attachment.html 


More information about the jboss-dev-forums mailing list