[infinispan-dev] ISPN-777 and dealing with stale locks

[Manik Surtani]

Yeah I think it is useful to share knowledge like this.

On 3 Dec 2010, at 16:39, Vladimir Blagojevic wrote:

> Excellent!! We should provide short summaries of all non-trivial fixes just as you did here!  
> 
> On 10-12-03 11:58 AM, Manik Surtani wrote:
>> 
>> Mircea's initial fix [1] for ISPN-777 was on the right track but incomplete, as witnessed by comments here [2]:
>> 
>> I've made a few more changes [3] to this which will now be in 4.2.0.CR3.  Anyway, the purpose of this email is to summarise my changes:
>> 
>> * Transactions self-destructing was only present on LockingInterceptor.visitLockControlCommand() [4].  This should also be on visiting prepare commands since this is the other place that locks can be acquired and a remote node disappearing.
>> * The check above is still not enough.  There is a race between conducting the check on a transaction and actually acquiring a lock.  E.g., a remote transaction may seem valid in [4] but by the time the thread acquires the lock, the node could have died rendering its transaction stale.  For this purpose, I have added a validity field to RemoteTransaction [5] which is flagged whenever a RollbackCommand is invoked [6] [7].  This allows the stale transaction cleanup task to flag such transactions as invalid even if they are being processed on the fly.  Finally, I have a check for this flag whenever locks are acquired and entries written to [8] and appropriate lock release if this is the case [9].
>> * I've also added a stress test that demonstrates this problem better (much more repeatable), based on the original test submitted by the reporter.
>> * Some other minor tweaks like better logging and toString() impls.  :-)
>> 
>> Cheers
>> Manik
>> 
>> [1] https://github.com/infinispan/infinispan/commit/51257cb
>> [2] http://community.jboss.org/thread/158844?tstart=0
>> [3] https://github.com/infinispan/infinispan/commit/ca0b28f314bb0a59edc0dfa7453f66fcd9162b26
>> [4] https://github.com/infinispan/infinispan/commit/51257cb#L1R148
>> [5] https://github.com/infinispan/infinispan/commit/ca0b28f314bb0a59edc0dfa7453f66fcd9162b26#L8R34
>> [6] https://github.com/infinispan/infinispan/commit/ca0b28f314bb0a59edc0dfa7453f66fcd9162b26#L4R56
>> [7] https://github.com/infinispan/infinispan/commit/ca0b28f314bb0a59edc0dfa7453f66fcd9162b26#L1R83
>> [9] https://github.com/infinispan/infinispan/commit/ca0b28f314bb0a59edc0dfa7453f66fcd9162b26#L8R74
>> [10] https://github.com/infinispan/infinispan/commit/ca0b28f314bb0a59edc0dfa7453f66fcd9162b26#diff-11
>> --
>> Manik Surtani
>> manik at jboss.org
>> Lead, Infinispan
>> Lead, JBoss Cache
>> http://www.infinispan.org
>> http://www.jbosscache.org
>> 
>> 
>> 
>> 
>> 
>> _______________________________________________
>> 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




-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20101203/05e3148d/attachment.html