[infinispan-dev] Re: Locking

[Vladimir Blagojevic]

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.