[infinispan-dev] Transactions across rehashes

[Manik Surtani]

Yeah makes sense.

On 9 Dec 2010, at 20:32, Mircea Markus wrote:

> 
> 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
> 
> 
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

--
Manik Surtani
manik at jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org