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.
David Lloyd wrote:
Tom Jenkinson wrote:
Plus I fear we will run out of space as I think you are encoding the full path of TMs in the XID?
Just the numeric path, which is why I recommended a compact notation. But yeah ultimately the tree depth and breadth is limited by the amount of bqual space using my scheme.
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.