[jboss-dev-forums] [JBoss Transactions Development] - Re: Remote txinflow: XID changes
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/630596#630596
--------------------------------------------------------------
Tom Jenkinson wrote:
Certainly we are adding this for remoting in the first instance so we want it to play
nicely with that!
One issue is the diamond question, e.g.
-> TM2
TM1 -> TM4
-> TM3
If we don't know the parent then both TM2 and TM3 will potentially try to recover TM4
for all indoubt transactions related to transactions initiated at TM1 which will have
undesirable recovery results.
Okay that makes sense, though isn't the parent
info in the gtid?
Tom Jenkinson wrote:
The other point is the bqual must have the EIS (JNDI) name in it as we have had
introduced this functionality for customers before to assist them in debugging transaction
related issues so we would definitely need to maintain this. That said, you were able to
get 600 resources into 3 bytes (out of the 64 available) so I dont anticipate leaving
space for the name being an issue (so long as we have a delimiter).
Ah okay. It
seems odd to me not to have that info just in the gtid - I suppose it's a space issue
at that point?
Tom Jenkinson wrote:
Finally, I maybe am not understanding your proposal correctly, a worked example would
help. What I can't quite understand is how the address space of the bqual will work in
a pyramid.
e.g:
-> TM2 -> RM1
TM1 -> TM3 -> RM2
-> RM3
Can you let me know what the resource number of each of the TMs and RMs are in that
picture so I can understand a little more clearly?
I think it would be like this:
* TM1->TM2: *0001* 0000
* TM2->RM1: *0001 0001*
* TM1->TM3: *0010* 0000
* TM3->RM2: *0010 0001*
* TM1->RM3: *0011* 0000
The 0000 are there to pad it out to a byte. Though this isn't actually a diamond.
Trying out a couple more just for the exercise...
In your top diamond where there are just four TMs in a diamond...
* TM2's prefix is 0001
* TM3's prefix is 0010
* TM4's prefix depends on whether TM2 or TM3 inflowed the work in question, it could
be 0001 0001 or 0010 0001.
Tom Jenkinson wrote:
Also, even with a solution to the diamond/pyramid approach (which I guess is achieved
because you pack the history into the bqual) for an example such as: 1000 0000 1000 0000,
how would I know whether or not this was a sequence of two sevens, and not 712 (comprised
of 128 for the binary +1 for the algorithm, +528 for the start of the range).
With our proposed approach you do not need to maintain the history of nodes in the bqual
as this can be determined from the top-down recovery scanning of parent/child node names
packed in the bqual resulting in a constant space use in the bqual of two ints.
Can we restrict the remoting node names down to values that can be converted uniquely to
an int ;)
Two sevens would be: 1000 0000 1000 0000, whereas 712 would be: 1110 0000 1000 0001
The number of leading '1' bits tells you how many additional nybbles to read. Put
another way:
* 0xxx
* 10xx xxxx
* 110x xxxx xxxx
* 1110 xxxx xxxx xxxx
* 1111 0xxx xxxx xxxx xxxx
* 1111 10xx xxxx xxxx xxxx xxxx
etc., thus every sequence is unique, and every row has 8 times more possible values than
the previous row.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/630596#630596]
Start a new discussion in JBoss Transactions Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&...]
Attachments:
- attachment.html (text/html — 7.9 KB)