JBoss Community

Tom Jenkinson wrote:

 

Just to round off the discussion:

 

Basically, I determined that the subordinate node name is not strictly a "node identifier" in the same sense as we are requiring it for a JTA gtrid value (which must be unique per object store). Instead it need only be unique per propagated transaction and the server does not need it to be the same value for different transactions flowed through the it, nor indeed must the value be globally unique (i.e. different servers can reuse the same id so long as it is not used by a different server within the scope of the same transaction).

 

All that that does need to happen is that the transport dynamically assign a unique integer for each node participating in a transaction, e.g. a counter starting at 1 and a recoverable mapping file be stored *by the transport* so that for any given transaction a server (keyed by the traditional String node identifier) knows what its own (now dynamic) "subordinate node name" was for the transaction, thereby assisting it with recovery.

 

To that end I have only had to change:

 

XID {

int:formatId

byte[]:gtrid { UID:sequence, String:nodeName }

byte[]:bqual {UID:sequence, String:EIS name }

}

 

To:

XID {

int:formatId

byte[]:gtrid { UID:sequence, String:nodeName }

byte[]:bqual {UID:sequence, int:subordinateNodeName, String:EIS name }

}

 

(i.e. added that single integer into the bqual).

OK here's my first wave of dumb questions:

1. Why do you need a UID in the bqual?
2. EIS name in this case is the local node's unique name for the subordinate it's planning on talking to, right?
3. If so why do we also need subordinateNodeName?  Just to create a way to differentiate between the "first" inflow versus subsequent?

Tom Jenkinson wrote:

 

I do have examples and tests for all of this:  https://svn.jboss.org/repos/labs/labs/jbosstm/branches/JBOSSTS_4_15_0_Final/atsintegration/tests and https://svn.jboss.org/repos/labs/labs/jbosstm/branches/JBOSSTS_4_15_0_Final/atsintegration/examples.

In particular, the example should prove to be extremely useful when developing the transport required for this as it shows and describes the points where relevant transaction data must be reliably persisted.

 

As I say, by reverting to a String node identifier, the solution is even closer to the original mechanism so therefore this new approach should have no impact on existing JTA/JCA work. The only difference now is that the space available to EIS namesis one byte shorter (from 36 to 35 bytes).

OK I'm trying to make sense of this code now w.r.t. our stuff.  More dumb questions:

1. It really looks like you're "handing off" a transaction between nodes so that only one has the transaction at a time, but in the real world many nodes in the graph may be performing useful work at the same time (potentially even from multiple threads) under the same (global) transaction.  How does this impact this scheme (from a TM perspective, not a transport perspective)?
2. You talk about not committing at the root node... should we be tracking the transactions by gtid and detecting the circular flow at the transport layer?  I assume that if that is the case, we'd use the original XID instead of the new alias and we'd treat commit requests of the alias XID as a "no-op" sort of thing.
3. It seems to me that we'd only have to persist the XID and enough information to revive a connection to the node corresponding to the XID, correct?

In the meantime I'm doing more reading, but the example code doesn't quite appear to be an accurate analog of our environment.