[infinispan-dev] Re: Locking
Manik Surtani
manik at jboss.org
Wed Apr 29 03:43:07 EDT 2009
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
More information about the infinispan-dev
mailing list