[Prev] Thread [Next]  |  [Prev] Date [Next]

[jbosscache-dev] Re: lock() and unlock() methods ? Brian Stansberry Fri Mar 20 07:01:18 2009

Bela Ban wrote:
Let's hear from others before we put anything on the roadmap.

I recall Brian mentioning his need for locks, but AFAIR not in conjunction with JBossCache but with Farming...

I have two use cases in my mind that involve something like cluster-wide locking. I don't think either matches what's being discussed here or is a real good general feature for JBC:

1) Clustered deployments. Not JBC-related.
2) Session ownership. There it's not a lock + try + dostuff + finally + unlock thing. It's more one node takes possession of the token for a session via a cluster wide call, and thereafter locks locally when using the session. It doesn't "unlock" via any cluster-wide call. On failover another nodes takes possession of the token. If the node holding the token is still alive and using it, it doesn't release the token until it is done.

Manik Surtani wrote:

On 20 Mar 2009, at 08:36, Bela Ban wrote:

I know, but what he wants to do is
#1 Read a value
#2 Based on that value (which I assume shouldn't change from underneath him), do some computations
#3 Write the changed value back

I guess the problem is that some other TX could change the value and have the later TX fail & roll back...

AFAIR we don't have Cache.lock(K) and unlock(K), do we ? If so, would it make sense to add them ? And then we'd have to think about

We don't at the moment. Adding them is simple, making them scale/perform well is hard. :-)

It would be a simple LockCommand which is broadcast (anycast?) via RPC. If it doesn't return (in time), assume we don't have the lock and throw a timeout exception. This call would *have* to be synchronous though, it can't work in an async manner.

  * how this fares with TX-incurred locking

It would hold the locks until unlock() is called, or a tx completes, whichever happens first, I guess.

  * what type of locks lock() acquires

Write locks. We don't have such a thing as read locks in Horizon or even JBC3's MVCC.


I don't mind putting it on the Horizon roadmap, but I can't promise when it would get done - its just a case of prioritising stuff. If another resource is looking unlikely/delayed we have a lot of stuff on our plate... :-(

Manik Surtani wrote:
No, a tx +RR is still optimistic cluster-wide in that it is only on tx commit (tx prepare, actually) that remote locks are acquired.

This essentially is a distributed lock.

On 20 Mar 2009, at 07:34, Bela Ban wrote:

Do we have a hard-lock mechanism like the one below for Coherence ?

Would a TX with RR be the equivalent ?

-------- Original Message --------
Subject:     RE: [javagroups-users] Distributed Lock Manager Listener
Date:     Thu, 19 Mar 2009 12:03:42 -0500
From:     Urciolo, Kevin J (IS) <[EMAIL PROTECTED]>
To:     Bela Ban <[EMAIL PROTECTED]>

I am trying to accomplish the locking mechanism as shown in this example
from Coherence.  I need to execute a piece of code that is mutually
exclusive throughout the group.

I looked at the VotingAdapter. I seemed to get the notifications before the lock was released, but caused the thread waiting for the lock to try
again too early and get another LockNotGrantedException.

NamedCache cache = CacheFactory.getCache("dist-cache");
Object key = "example_key";
cache.lock(key, -1);
 Object value = cache.get(key);
 // application logic
 cache.put(key, value);
 // Always unlock in a "finally" block
 // to ensure that uncaught exceptions
 // don't leave data locked
-----Original Message-----
From: Bela Ban [mailto:[EMAIL PROTECTED] Sent: Thursday, March 19, 2009 4:48 AM
To: Urciolo, Kevin J (IS)
Subject: Re: [javagroups-users] Distributed Lock Manager Listener

Urciolo, Kevin J (IS) wrote:
I would like to use the distributed lock manager. However, I would like my components to block until a lock is available instead of getting an exception thrown.

What if the lock cannot be granted ? There's a LockNotGrantedException
when this happens. I also assume you would not want to wait forever if a
lock is held by a different owner.

Is this possible? If not, is it possible to listen for events on locks

so I can implement my own listener mechanism?

There's a VotingAdapter class which implements VoteResponseProcessor. This class has callbacks, but of course you could also write your own

Bela Ban
Lead JGroups / Clustering Team
JBoss - a division of Red Hat

Bela Ban
Lead JGroups / Clustering Team
JBoss - a division of Red Hat

Manik Surtani
Lead, JBoss Cache

Bela Ban
Lead JGroups / Clustering Team
JBoss - a division of Red Hat

Manik Surtani
Lead, JBoss Cache

Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
jbosscache-dev mailing list