JBossDeveloper

> In either scenario, the administrator is going to need to keep a mapping file. Either remoting node identifier to transaction manager node name (my preference) or EIS name to EIS int key.

That's not quite right. EIS names are scoped to the node and the mapping can be maintained programmatically by e.g. the JCA xa recovery plugin registration code.  The nodeIdentifier is potentially enterprise (or at least data centre) scoped and needs manual coordination and maintenance or some centralized/hierarchic registry service to manage uniqueness. Than again so does allocation of a uniq string node name in the first place.

I can see wanting the node name for debugging purposes in the gtid (for the originator) and bqual (for the branch node).  We'd have to make sure that we truncate names which are too long though as the limit for node names is currenty 255 characters (though we could reduce it further, as the maximum length of a host name label is 63 (recommended maximum length is 24)).

But what I'm not clear on is, why exactly do we need the other node names in the XID?  I think that come out of off-forum discussions and without that information I can't really offer up any ideas.  It seems like we should be able to take advantage of the unique topography of this scheme to provide some of the information.

> for EIS name was administrator would still need to keep a mapping of EIS JNDI name to EIS "short" name

No, the server can simply allocate and store a new uniq short EIS name for any long name it has not seen before. Because the server has view over the entire scope, so that mapping process can be automated.  That's the key difference with nodeIdentifier - a server does not have sufficient local information to allocate itself a globally uniq node id.

Tom Jenkinson wrote:

 

Jonathan Halliday wrote:

 

> In either scenario, the administrator is going to need to keep a mapping file. Either remoting node identifier to transaction manager node name (my preference) or EIS name to EIS int key.

 

That's not quite right. EIS names are scoped to the node and the mapping can be maintained programmatically by e.g. the JCA xa recovery plugin registration code.  The nodeIdentifier is potentially enterprise (or at least data centre) scoped and needs manual coordination and maintenance or some centralized/hierarchic registry service to manage uniqueness. Than again so does allocation of a uniq string node name in the first place.

 

Agree with you here, the scope of the EIS name needs to be unique within the node, so it can be shorter. I think I maybe wasn't 100% clear but what I mean for EIS name was administrator would still need to keep a mapping of EIS JNDI name to EIS "short" name which is what I meant by keeping a mapping file in that scenario. At the moment the EIS name is read from the JCA configuration that says "jndi-data-source-name" basically (typically). If we no longer use that value then basically an extra bit of configuration (which I was terming mapping) must be held to say for XYZ data source it has a JNDI name of "foo" and a XAResourceWrapper identifier of "bar" - well, most likely a shorter version of foo

From the Remoting perspective, the EIS name would most likely just be the full node name of the calling node.  If I mix these two up in the future, this is why.

Tom Jenkinson wrote:

 

To be clear, the EIS name is the only debugging information in the XID.

 

XID:

formatId

gtrid { sequence, root node name }

bqual { sequence, subordinate node name, parent node name, eis name }

 

sequences are vital naturally

root node name is vital to detect orphans at the root in recovery

subordinate node name is vital to detect orphans at subordinates

parent node name is optional to filter list of recovered XIDs at a remote server by the caller

eis name is debugging

Okay so here's where my confusion came in.

When I suggested that sequence idea, the thought was that root node + sequence is basically equivalent to (subordinate node name + parent node name) in that any participant should be able to tell whether a branch belonged to it or its descendants, and also should be adequate for filtering recovered XIDs.  But I'm not sure what you mean by "orphans" exactly - aren't all branches normally recovered by the root?  If so, does the subordinate path actually matter?

> From the Remoting perspective, the EIS name would most likely just be the full node name of the calling node

Nope, it's the name of the target node, not the originating node. If you have one parent server talking to two subordinate servers, that's two distinct EIS names, because the parent has to be able to tell the subordinates apart for recovery purposes, just as it has to be able to tell apart e.g. the Oracle and MSSQL server dbs it's talking to through the same mechanism.  Which brings up back to the other list the parent needs to maintain: a set of all the subordinates it's talked to. Well actually it's the set of all subordantes with outstanding tx, but deleting items from the list frequently is probably more trouble than its worth.

Jonathan Halliday wrote:

 

> From the Remoting perspective, the EIS name would most likely just be the full node name of the calling node

 

Nope, it's the name of the target node, not the originating node. If you have one parent server talking to two subordinate servers, that's two distinct EIS names, because the parent has to be able to tell the subordinates apart for recovery purposes, just as it has to be able to tell apart e.g. the Oracle and MSSQL server dbs it's talking to through the same mechanism.  Which brings up back to the other list the parent needs to maintain: a set of all the subordinates it's talked to. Well actually it's the set of all subordantes with outstanding tx, but deleting items from the list frequently is probably more trouble than its worth.

Ah, you're just looking at it from the opposite end; however the point still stands that the EIS name is equal to the node name.  If I set up a Remoting connection into the EJB client, the node (and cluster) name of the remote side is noted for various purposes.  This also has the advantage that a node can be contacted via a different configuration, socket, or protocol and still be recognized which allows us to port over UserTransaction as well as stateful EJBs to new connections.  It should also help us with this issue.

> But I'm not sure what you mean by "orphans" exactly - aren't all branches normally recovered by the root?  If so, does the subordinate path actually matter?

An orphan is a prepared RM whose immediate parent has died without writing a log. Under presumed abort it has got to be rolled back. Only the immediate parent can do that - NOT the root (unless they are the same). The reason is simple: only the immediate parent can recognize the orphan status, as it's a function of the absence of a log record at that location. Also, in some deployments only the immediate parent may have the driver and connection details to reach that orphan - they are not guaranteed to be available at the root.  Part of the reason that nodes need a uniq id is that encoding it into the Xid allows them to recognize their own orphaned branches and likewise avoid tampering with ones they don't own.  You can actually eliminate the need for globally uniq idfor this purpose by writing to the log twice - once before and once after preparing the RM, in which case you don't get orphans any more. The cure is worse than the disease though - those log writes to disk drop your performance to unacceptable levels and you still need a globally uniq value of some form for generating uniq tx ids anyhow.

Ah I see I said it backwards, my bad,

Okay so the point is to avoid recovering orphans until the parent comes back online, and then letting the parent do it?  Because the hierarchical sequence thing works for that too (it's easy to tell when there's an orphan because every node knows exactly which subordinates it "owns").