[jbosscache-dev] Re: lock() and unlock() methods ?

[Brian Stansberry]

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 at ngc.com>
>>>>> To:     Bela Ban <belaban at yahoo.com>
>>>>> CC:     <javagroups-users at lists.sourceforge.net>
>>>>> References: 
>>>>> <0E36CF63779A934D876C5E7FD29E74EB01FA4FFC at XMBIL123.northgrum.com> 
>>>>> <49C206DC.8030608 at 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 at yahoo.com] Sent: Thursday, March 19, 
>>>>> 2009 4:48 AM
>>>>> To: Urciolo, Kevin J (IS)
>>>>> Cc: javagroups-users at 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 at jboss.org
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>> -- 
>>> Bela Ban
>>> Lead JGroups / Clustering Team
>>> JBoss - a division of Red Hat
>>>
>>
>> -- 
>> Manik Surtani
>> Lead, JBoss Cache
>> http://www.jbosscache.org
>> manik at jboss.org
>>
>>
>>
>>
>>
> 


-- 
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
brian.stansberry at redhat.com