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...
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
--
Bela Ban
Lead JGroups / Clustering Team
JBoss - a division of Red Hat