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

[Jason T. Greene]

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


-- 
Jason T. Greene
JBoss, a division of Red Hat