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

[David Lloyd]

David Lloyd [http://community.jboss.org/people/dmlloyd] created the discussion

"Re: Remote txinflow: XID changes"

To view the discussion, visit: http://community.jboss.org/message/630683#630683

--------------------------------------------------------------
> Tom Jenkinson wrote:
> 
> I think I understand your notation approach now and can understand how it might work (assuming we can determine a delimiter to use to seperate the path from the eis name [typically the JNDI name]).
> 
> That said, and with the restriction in mind that you have outlined below, are you sure that managing node names as ints rather than strings is an overhead to the deployer that is "totally unacceptable" (my words, not yours)? I have attached a "git diff" of the transaction work which shows where I would anticipate the AS changes required, you will note that currently the node name is being hard coded as "1", I have just hard coded it as 1 instead in my patch but I would suggest removing the hardcoding of the name from the Java code and hard code it in the XML instead to make it clear that a user must change it if they have more than one node.
When I say "node name" I'm generally referring to the JBossAS/Remoting concept of a name for the instance itself, which is by default derived from the host name of the system (but is modifiable in the event of, say, multiple instances running on one host).  But this node name is basically of arbitrary length, so encoding it into bqual (as-is) is not an option no matter what.  That said, it would be nice if TS and AS had the same notion of node name.

As far as int IDs go, forcing the user to define a unique integer ID for each possible participant is indeed probably too great an administrative/management burden, and it's not terribly user-friendly for reading purposes either; at least, I don't relish selling the idea to support or the community (nor trying to explain it for that matter).  But, my approach was based on the sole requirement that any node in the hierarchy should be able to independently generate an ID which is definitely unique globally for that gtid.  So it doesn't really take into account other requirements, such as puting human-readable debug info in the XID, in the first place.


> Tom Jenkinson wrote:
> 
> As of last night I have (or indeed, had, as I did it before this part of the conversation resumed) put back a fix to TS that converts the XID with the parent and child encoded in the bqual, I can easily back this out and go with your approach but I see at least the following advantage to mine:
> 
> The number of nodes in the tree is not bounded by 64 bytes as we only encode the node of the subordinate and its parent
> 
> The drawback is that an administrator would need to configure each AS with a remoting node name, plus a TS integer node name.
Well... that could still be a viable approach even with string names, maybe.  With 64 bytes to fill but only one or two names to fill it with, it seems somewhat more realistic than trying to store an entire chain of names (even if the name ends up being an abbreviated form of the system node name).  Recovery can't really take advantage of that information as robustly though (to use that information for recovery you'd have to restore not only all the nodes but all the original paths between them, even if they are redundant), so other than debug purposes, there doesn't seem to be a lot of advantage.  One other possible weakness is that if two nodes have the same identifier, this is one more place where that can cause a problem (granted the user really shouldn't do that).  Also, while a node typically knows what nodes it is talking to, it doesn't know what nodes are talking to it on the inflow side (other than by whatever info we stuff in the XID).

One characteristic of my approach which might turn out to be a weakness is that the resource IDs would essentially be numbered sequentially based on the order in which they enrolled in the transaction, so the numbering isn't really relevant in any real sense outside of it.  Now theoretically, it seems that a node could tell which XIDs were initiated by it based on what unrecovered XIDs the local TM has pending, and doing a prefix comparison.  So it could use that information to resolve the whole transaction branch while only sending its own corresponding XID to the parent (which it would only do if all of the known immediate subordinate XIDs were known to be available for resolution).  I don't know if this holds up for cyclic graphs though - if re-entered nodes don't interally combine the transactions with the same gtid then it'd probably work fine I guess (re-entered nodes could maybe optimize such transactions by internally always using the shortest, lowest, or least recent XID bqual available that it knows about for a given gtid, instead of the one that was inflowed, which could avoid a "split-brain" kind of recovery situation).

I guess I don't know enough about the subtleties of the recovery process to say one way or the other with any authority, other than to just give a brain dump of thoughts as they arrive.
--------------------------------------------------------------

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

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/20111007/27810fdf/attachment.html