The old lock manager was slightly out of alignment with the normal
semantics of these methods - in the new lock manager the following
holds:
lock - is blocking (cannot be interrupted)
tryLock(no timeout) - does not throw InterruptedException
tryLock(with timeout) - can be interrupted (throws InterruptedException)
lockInterruptibly - is blocking (but can be interrupted)
Not sure how this is exposed by FinegrainedLock - but this is what is
going on in the core.
Chris
On Nov 11, 2009, at 10:51 AM, Alex Miller wrote:
Given those alternatives, I'd much rather add a tryLockEntry() :)
Let me discuss with some people here internally and see whether we
can add this for the 3.2 release train.
I'll leave the interrupt question to Chris (who is out today) since
he just rewrote the client lock manager. In this case, I think
you're performing a blocking lock operation so I don't believe it
should/would respond to interrupt.
BTW, you might want to try out some of your perf tests with the
current trunk - server guys have made some insane improvements in
the last few weeks in prep for 3.2 plus the new lock mgr is a big
improvement, particularly on read locks and lock memory footprint.
On Nov 11, 2009, at 9:32 AM, Sergio Bossa wrote:
On Wed, Nov 11, 2009 at 4:20 PM, Alex Miller <[email protected]
> wrote:
My only concern with that is that LockableMap touches a lot of
public (and
private) stuff across tim-concurrent-collections, tim-distributed-
cache,
tim-hibernate-cache, etc:
I see your concerns ...
Maybe it would be better to add it just to
ConcurrentDistributedMap directly
and not LockableMap for the moment?
I was thinking at LockableMap in order to be consistent with already
existing interfaces: adding such a method directly on
ConcurrentDistributedMap would absolutely work for me, but I don't
want to mess your code, so feel free to review the issue with your
transparency team if needed and keep me posted.
As an alternative solution, I was thinking to write a
ContentionManager to simply kill threads contending/waiting-for locks
for too much time, so I have another question: is it possible to
interrupt a thread waiting on ManagerUtil.beginLock(...)?
--
Sergio Bossa
Software Passionate and Open Source Enthusiast.
URL: http://www.linkedin.com/in/sergiob
_______________________________________________
tc-dev mailing list
[email protected]
http://lists.terracotta.org/mailman/listinfo/tc-dev
_______________________________________________
tc-forge-dev mailing list
[email protected]
http://lists.terracotta.org/mailman/listinfo/tc-forge-dev
_______________________________________________
tc-dev mailing list
[email protected]
http://lists.terracotta.org/mailman/listinfo/tc-dev
