[infinispan-dev] Key locking order in LockingInterceptor

[Manik Surtani]

Hmm, yes lets chat next week.

In general I agree with Galder in that -1 to keys being Comparable.  This is a pretty poor restriction to place on end users.

On 14 Jun 2010, at 15:20, Vladimir Blagojevic wrote:

> I am still a novice in decoding these lock timeout stacktraces:( I looked around the code to see how it might happen and then I saw this (IMHO) problem staring back at me. I am not saying lock ordering is the the cause of this particular problem. I do not know. Lets talk more about it next week.
> 
> 
> On 2010-06-14, at 4:15 AM, galder at jboss.org wrote:
> 
>> Which threads are involved here in the potential deadlock you're talking about?
>> 
>> I'm not sure we could enforce comparable keys since they're outside of the scope of what we can control and keys might not be comparable at all.
>> 
>> Using Comparable though in a test, you might be able to figure out whether the issue is caused by ordering. I.e. you could have two keys which order is swapped at runtime. However, even without using Comparable, it should be relatively easy to spot an issue with locking ordering in the logs (assuming thread info is in logs) cos LockManagerImpl.lockAndRecord logs attempts to locks and whether these were successful.
>> 
>> ----- "Vladimir Blagojevic" <vblagoje at redhat.com> wrote:
>> 
>>> Hi,
>>> 
>>> I am trying to figure out why SingleJoinTask sometimes fails due to
>>> TimeoutException. I noticed that invalidate command sends out bunch of
>>> keys to be invalidated across cluster and in turn LockingInterceptor
>>> tries to lock these keys one by one. In few other methods
>>> LockingInterceptor also tries to lock a list of keys sequentially.
>>> Without knowing the full details of locking mechanism this practice
>>> seems to be dangerously susceptible to deadlocks. Shouldn't we require
>>> all keys to be Comparable so that we can order keys prior to any
>>> locking attempts in LockingInterceptor.
>>> 
>>> Maybe I am not understand all the details; I would like to be proven
>>> that I am completely off :)
>>> 
>>> Regards,
>>> 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
> 
> 
> _______________________________________________
> 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