[infinispan-dev] Transactions across rehashes

Vladimir Blagojevic vblagoje at redhat.com
Thu Dec 9 11:21:16 EST 2010


Continuing our conversation related to ISPN-799 that I have to fix soon 
:-) In summary, the real reason why tx fails for SingleJoinTest is 
actually a tx T being prepared for nodes A,B prior to rehash event 
triggered due to join and then committed on nodes A,C after the rehash. 
Manik, and I talked briefly on IRC and concluded that it is better to 
detect these cases and issue a rollback rather than deal with all the 
edge cases arising from handling "tx across rehashes" scenario.

If we do not detect such cases of "tx across rehashes" (which should 
occur rarely) the consequence is that some prepared tx will not be 
committed and the locks will remain on keys until stale lock cleanup 
mechanism or timeout kicks in.

In order to detected and implement handling tx across rehashes I need 
your input Mircea. I was looking at recording either a ch used to issue 
prepare or list of nodes where tx was prepared. When later, commit is 
issued, list of nodes to send commit to is compared to prepared list. If 
they are not equal tx is marked for rollback. Same with a hash expect a 
different hash might map keys to same nodes. Mircea, can this state 
(either ch or list) be stored in global tx. Or you have some better ideas.

Let me know WDYT.


More information about the infinispan-dev mailing list