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