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