IMO we need lock(K key, boolean eager), and no unlock method. We can just unlock when a transaction is completed. Then we dont have to worry about a user forgetting to unlock in a finally.

The eager flag indicates whether or not to acquire the lock on the whole cluster *now*, or wait until replication time. Right now you can accomplish the later by writing to an arbitrary key, but this wastes marshaling. The former is important when you want to have things like counters.

Brian Stansberry wrote:

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.

WDYT ?

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) <Kevin.Urciolo@ngc.com>

To:     Bela Ban <belaban@yahoo.com>

CC:     <javagroups-users@lists.sourceforge.net>

References: <0E36CF63779A934D876C5E7FD29E74EB01FA4FFC@XMBIL123.northgrum.com> <49C206DC.8030608@yahoo.com>

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);

try

{

Object value = cache.get(key);

// application logic

cache.put(key, value);

}

finally

{

// Always unlock in a "finally" block

// to ensure that uncaught exceptions

// don't leave data locked

cache.unlock(key);

}

-----Original Message-----

From: Bela Ban [mailto:belaban@yahoo.com] Sent: Thursday, March 19, 2009 4:48 AM

To: Urciolo, Kevin J (IS)

Cc: javagroups-users@lists.sourceforge.net

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

implementation

--

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

http://www.jbosscache.org

manik@jboss.org

--

Bela Ban

Lead JGroups / Clustering Team

JBoss - a division of Red Hat

--

Manik Surtani

Lead, JBoss Cache

http://www.jbosscache.org

manik@jboss.org

--
Jason T. Greene
JBoss, a division of Red Hat
_______________________________________________
jbosscache-dev mailing list
jbosscache-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosscache-dev