[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