Re: [infinispan-dev] Re: Locking

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()