[jboss-dev-forums] [JBoss Transactions Development] - Re: Remote txinflow: XID changes

[David Lloyd]

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&containerType=14&container=2041]

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jboss-dev-forums/attachments/20111007/4cc17f2f/attachment.html