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

[Tom Jenkinson]

Tom Jenkinson [http://community.jboss.org/people/tomjenkinson] created the discussion

"Re: Remote txinflow: XID changes"

To view the discussion, visit: http://community.jboss.org/message/630604#630604

--------------------------------------------------------------
> David Lloyd wrote:
> 
> > 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?

Only the root TM would be in the gtrid, we can't edit that as the transaction flows.


> David Lloyd wrote:
> 
> 
> > 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?
Again, each RM will need to put its own name in the XID so again we can't cat this into the gtrid


> David Lloyd wrote:
> 
> 
> 
> > 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.
> 

Understood - thanks!
> David Lloyd wrote:
> 
> 
> > 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.

Ah, understood. I was thinking the first few bits were binary, hence 100 could have been either read as 1 (for 1 trailing nybble) or 100 (for 4). Now I get you, the prefix is the number of nybbles, like in roman numerals.

If it is 0 terminated as you show above though, it looks like 1111 10xx xxxx xxxx xxxx xxxx should really be 1111 10xx xxxx xxxx xxxx xxxx xxxx (five trailing nybbles AFTER the nybble where the counter prefix finishes? Or should it be read as the number of "total number of nybbles (less one) that the number is read from". E.g in your last case the number has been encoded in 5 plus 1 nybbles.

Anyway, for the purposes of the discussion I get what you are proposing, I guess the question would be when it comes to recovery, when the node recovers how does it know which XIDs it should be looking for? With my proposal where the node is configured with a node ID via the CoreEnvironmentBean it can look in the XID for a match, in your scenario how would it know?

Plus I fear we will run out of space as I think you are encoding the full path of TMs in the XID?
--------------------------------------------------------------

Reply to this message by going to Community
[http://community.jboss.org/message/630604#630604]

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/df9e4e73/attachment.html