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(a)jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org