[infinispan-dev] Re: Locking

Manik Surtani manik at jboss.org
Wed Apr 29 03:51:07 EDT 2009


On 28 Apr 2009, at 22:14, Bela Ban wrote:

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

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

Cheers
--
Manik Surtani
manik at jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org







More information about the infinispan-dev mailing list