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/630600#630600 -------------------------------------------------------------- An alternative, but equivalent, encoding would be to mark each nybble with a "more" bit - if the bit is "1" then the next nybble has more bits, with the last nybble starting with 0: *1*001 *1*010 *1*000 *0*001 -> 001 010 000 001 Same idea, really. -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/630600#630600] Start a new discussion in JBoss Transactions Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&...]

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/630611#630611 -------------------------------------------------------------- But for recovery we only need the root TM right?  That would eliminate the risk of a subordinate TM recovering a branch of a transaction because it would recognize that it wasn't the root? Okay, so the gtid gets the root TM's name and the bqual gets the RM name (assuming such things have names)? Well, I meant 5 nybbles holding data however after reviewing I guess that's not really correct.  It would be more correct to say "the number of nybbles in the total encoded number = the leading number of 1s plus 1".  With 0000 being a special case. Assuming that transactions should only be recovered by the root node which originated it, we would just use gtid to identify the "ownership" of the transaction.  Otherwise, all the known unrecovered XIDs from the node itself plus its subordinates should be propagated back upon recovery request.  I'd also need some kind of loop detection at the protocol level though. We could potentially optimize this process by using our knowledge of the XID format to filter the XID list by owner name before sending it back to the requestor. -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/630611#630611] Start a new discussion in JBoss Transactions Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&...]

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/630657#630657 -------------------------------------------------------------- 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. 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. Just trying to get some definitive clarity to prevent me having to rewrite this thing again. But if you go with my current approach "We could potentially optimize this process by using our knowledge of the XID format to filter the XID list by owner name before sending it back to the requestor." will be handled by the XID. -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/630657#630657] Start a new discussion in JBoss Transactions Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&...]

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 -------------------------------------------------------------- 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. 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&...]