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.