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

[Vladimir Blagojevic]

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 <mailto: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

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