[jboss-dev-forums] [Design of JBossCache] - Re: New state transfer in JBoss Cache

[bstansberry@jboss.com]

anonymous wrote : D doesn't care about conflicting remote prepares since at least someone else  in the cluster would have detected this and the prepare would roll back anyway.
  | 

Here's the specific scenario I was thinking about when I mentioned "one concern is D receives things in different order than A did due to message retransmission."

You've got {A, B, C} with new joiner D.

Messages as seen by {A, B, C}

1) B:PREPARE-TX1
2) B:COMMIT-TX1
3) C:PREPARE-TX2
4) C:COMMIT-TX2

TX1 and TX2 have a locking conflict, but there is no issue due to above ordering.

But, D has a hiccup and drops message 2, requiring JGroups retransmission. Our JGroups stacks don't provide total ordering, just ordering from the same sender. So, now D sees and queues the sequence as:

1) B:PREPARE-TX1
2) C:PREPARE-TX2 -- oops blocks!!
3) B:COMMIT-TX1 -- doesn't get taken off queue due to block
4) C:COMMIT-TX2

When D drains the queue, message #2 will block due to lock conflict, preventing the needed message #3.
 
JGroups' concurrent stack avoids that kind of problem during normal operation by allowing the B and C messages to be processed in parallel. :-) But, as soon as you introduce a single queue, you can get the problem back again. (The message reordering thing I mentioned was meant to help deal with that by scanning the queue and trying to handle B:COMMIT-TX1 before C:PREPARE-TX2.)

This is kind of an edge case, but it's there.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4113531#4113531

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4113531