[infinispan-dev] Re: Locking

[Manik Surtani]

Yes - and for (B) we'd need a new config option to switch this on.   
Probably a part of the <transaction /> tag rather than the <locking />  
tag.

On 30 Apr 2009, at 15:43, Vladimir Blagojevic wrote:

> Ok, I agree with you. This is a valid use case! To summarize, so far  
> we have two valid use cases:
>
> A) Explicit eager locking + transactions
>
> tx.begin()
> cache.lock(K)
> cache.put(K,V)
> tx.commit()
>
> B) Implicit eager locking + transactions
>
> tx.begin()
> cache.put(K,V)      // acquire cluster wide lock on K
> cache.put(K2,V2)  // acquire cluster wide lock on K2
> cache.put(K,V5)    // no-op, we already own cluster wide lock for K
> tx.commit()
>
>
>
>
>
> On 4/30/09 5:11 AM, Manik Surtani wrote:
>>
>> Finer grained control.  A user may not want eager locking by  
>> default, *unless* something happens.  In which case he does.  For  
>> example, eager locking makes a lot of sense when updating a shared  
>> counter.  So:
>>
>> tx.begin()
>> // read stuff.  Don't really care about eager locking here.
>> // some condition is true.  Doesn't happen often, maybe 10% of the  
>> time.
>> // need to update a shared counter here!  I'd rather have eager  
>> locks!
>> cache.lock(counter_key)
>> cache.put(incremented_counter_value)
>> tx.commit()
>>
>> Granted it's not a very common use case, but eager locking as a  
>> whole is not a very common use case.  But still an important one.
>> -- 
>> Manik Surtani
>> manik at jboss.org
>> Lead, Infinispan
>> Lead, JBoss Cache
>> http://www.infinispan.org
>> http://www.jbosscache.org
>>
>>
>>
>>
>

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