[infinispan-dev] Re: Locking
Bela Ban
bban at redhat.com
Tue Apr 28 17:14:31 EDT 2009
Manik Surtani wrote:
> A. Transactions + Eager locking
> ---------------------------------
>
> when you do the following:
>
> 1. tx.begin()
> 2. cache.put(K, V)
> 3. tx.commit()
>
> what happens is, at 1., a new GTX instance is associated with the
> transaction. At 2. locks are acquired on K on the *local* cache, the
> owner being GTX. At 3., a prepare() is broadcast and the locks on K
> are acquired on all remote participating caches, the owner being GTX
> again.
>
> The GTX is propagated with the PrepareCommand as it is a field in
> AbstractTransactionBoundaryCommand.
>
> So now, an explicit lock in the scope of a transaction would also need
> to propagate the GTX - just so we know who the lock owner should be.
> E.g.,
>
> 1. tx.begin()
> 2. cache.lock(K)
> 3. // read K,V and calculate V2 which is a function of V. E.g., V2 =
> V + 1
> 4. cache.put(K, V2)
> 5. tx.commit()
>
> In the above scenario, step 2 broadcasts a LockControlCommand which is
> constructed with the GTX and the necessary key(s). Remote caches
> acquire the locks using the GTX as the owner, and responds
> positively. (this RPC call would *have* to be sync regardless of
> cache mode).
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()
--
Bela Ban
Lead JGroups / Clustering Team
JBoss - a division of Red Hat
More information about the infinispan-dev
mailing list