[infinispan-dev] Transactions across rehashes

[Mircea Markus]

On 9 Dec 2010, at 16:21, Vladimir Blagojevic wrote:

> Hey,
> 
> 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.
+1. That would make the code unnecessarily complicated.
> 
> 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.
I like it.
You might be able to use the LocalTxInvocationContext.remoteLocksAcquired() method.
This tracks the nodes where locks are being acquired during eager locking process (DistInterceptor.visitLockControlCommand) and uses this list in the StaleTransactionCleanup.onViewChange for marking these transactions for rollback.
In fact I think that the only thing that needs to be done is to add the LocalTxInvocationContext.remoteLocksAcquired calls in the DistInterceptor.vistiPrepareCommand (or visitCommitCommand if 1PC is enabled).
> Let me know WDYT.
> 
> Cheers,
> Vladimir
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev