[infinispan-dev] Re: Locking

[Manik Surtani]

On 29 Apr 2009, at 15:18, Vladimir Blagojevic wrote:

> On 4/29/09 3:51 AM, Manik Surtani wrote:
>>
>> On 28 Apr 2009, at 22:14, Bela Ban wrote:
>>>
>>> I'm thinking whether it would make sense to be able to configure  
>>> eager locking on a TX level in the XML config. Then we could invoke
>>>
>>> 1. tx.begin()
>>> 2. cache.put(K,V)
>>> 3. tx.commit()
>>>
>>>
>>> In step #2, rather than a local lock, we would acquire a cluster  
>>> wide lock (or cluster subset for DIST), and release it on  
>>> commit(). For each modification, we check if there is already a  
>>> lock available *locally*. If there is, we already hold the global  
>>> cluster wide lock and don't do anything, else we acquire the  
>>> cluster wide lock.
>>>
>>> So for
>>>
>>> 1. tx.begin()
>>> 2. cache.put(K,V)      // acquire cluster wide lock on K
>>> 3. cache.put(K2,V2)  // acquire cluster wide lock on K2
>>> 4. cache.put(K,V5)    // no-op, we already own cluster wide lock  
>>> for K
>>> 5. tx.commit()
>>>
>>
>> Yes.  Transparent eager locking for transactions could be enabled  
>> once we actually have explicit eager locking (for transactions,  
>> again) in place.  I think they both have their uses and we should  
>> start with the explicit (use of the lock() method).  Adding  
>> transparent eager locking on top of this should be easy.
>>
>> https://jira.jboss.org/jira/browse/ISPN-70
>
> I would argue that Bela's use case pinpoints a feature that has the  
> most potential for actually doing something very useful while at the  
> same time does not introduce additional complexity and a can of  
> worms problems related to misuse of API use/configuration mentioned  
> by Manik an Mircea. Which brings me to a question: Do we really need  
> to expose lock/unlock API? Why don't we implement cluster wide  
> locking as outlined in the example above and forget the rest! I am  
> willing to change my opinion if one can successfully argue that we  
> really need it but from the discussion we had so far I still do not  
> see valid reasons.

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