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

Fri Mar 20 07:14:29 EDT 2009

I can see some use when using a distributed cache as a distributed  
file system (JCR, etc)...

On 20 Mar 2009, at 09:14, 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...
>
>
> 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
>>
>>
>>
>>
>>
>
> -- 
> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbosscache-dev/attachments/20090320/05fd7fa1/attachment.html 