[infinispan-dev] Re: Locking

[Vladimir Blagojevic]

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