[infinispan-dev] ISPN-777 and dealing with stale locks
manik at jboss.org
Mon Dec 6 09:38:55 EST 2010
Hmm, it doesn't seem 100% complete as yet. Even with my stress test, when using JBossTM one in about 20 runs fails with a stale lock leftover.
On 6 Dec 2010, at 14:25, Mircea Markus wrote:
> Thanks for the fix mate!
> On 3 Dec 2010, at 14:58, Manik Surtani wrote:
>> Mircea's initial fix  for ISPN-777 was on the right track but incomplete, as witnessed by comments here :
>> I've made a few more changes  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() . 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  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  which is flagged whenever a RollbackCommand is invoked  . 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  and appropriate lock release if this is the case .
>> * 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. :-)
>>  https://github.com/infinispan/infinispan/commit/51257cb
>>  http://community.jboss.org/thread/158844?tstart=0
>>  https://github.com/infinispan/infinispan/commit/ca0b28f314bb0a59edc0dfa7453f66fcd9162b26
>>  https://github.com/infinispan/infinispan/commit/51257cb#L1R148
>>  https://github.com/infinispan/infinispan/commit/ca0b28f314bb0a59edc0dfa7453f66fcd9162b26#L8R34
>>  https://github.com/infinispan/infinispan/commit/ca0b28f314bb0a59edc0dfa7453f66fcd9162b26#L4R56
>>  https://github.com/infinispan/infinispan/commit/ca0b28f314bb0a59edc0dfa7453f66fcd9162b26#L1R83
>>  https://github.com/infinispan/infinispan/commit/ca0b28f314bb0a59edc0dfa7453f66fcd9162b26#L8R74
>>  https://github.com/infinispan/infinispan/commit/ca0b28f314bb0a59edc0dfa7453f66fcd9162b26#diff-11
>> Manik Surtani
>> manik at jboss.org
>> Lead, Infinispan
>> Lead, JBoss Cache
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
manik at jboss.org
Lead, JBoss Cache
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the infinispan-dev