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(a)jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org