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