[infinispan-dev] Re: Locking

[Manik Surtani]

On 28 Apr 2009, at 22:28, Mircea Markus wrote:

> Manik Surtani wrote:
>>

<SNIP />

>> Here, we notice that explicit use of unlock() is needed to release  
>> locks acquired by lock(), unlike the case where a committing (or  
>> rolling back) transaction would do this for you.
>>
>> The tricky thing here is, who holds lock ownership across a  
>> cluster?  :-)  If this is standalone mode, this is simple - the  
>> Thread-owner paradigm works fine.  Perhaps we need to change the  
>> locking code so that the non-tx lock owner is a combination of  
>> thread-name + cache address?  I can see this leading to tricky  
>> stale locks though if we have a join/rejoin midway during a code  
>> sequence like above.
> yep this gets tricky indeed. I'm just thinking whether we want to  
> support this (i.e. non tx+eager locking), as it might unnecessarily  
> complicates things: eager locking involves the idea of a session, as  
> the lock scope should be defined.  Another approach than tx might be  
> to use the batch api, and only allow cache.lock() statements within  
> cache.startBatch()

Yes.  And this is why it makes sense to allow eager locking within  
transaction scope.  Batches use JTA transactions behind the scenes so  
the same scoping rules apply.

>
>>
>> D.  No transaction + Non-eager locking
>> ---------------------------------
>>
>> Just as in B., I'm not sure if this is a valid use case.  I.e., how  
>> is this useful and what is its purpose.  (perhaps just acquire  
>> local locks on lock() and only acquire the remote locks when the  
>> actual put() is performed?)
>>
>>
>>
>> Anyway, to sum things up: the way I see it, B and D are cases that  
>> still need further thought (i.e., the non-eager cases).
> I might be missing something, but the current implementation doesn't  
> do exactly that: non eager locking?

Yes and no.  Yes in that the locking is non-eager, but no in that you  
don't have fine-grained control over the duration which locks are  
held.  E.g., cache.put() holds the write lock purely for the duration  
of the put() call.  You may want to do something like:

x = cache.get()
cache.put(x + 1)

and have the write lock across the two invocations, but IMO that is a  
better use case for a transaction than some explicit, eager locking  
thing.  :-)

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