[jbosscache-dev] Re: lock() and unlock() methods ?
Manik Surtani
manik at jboss.org
Thu Mar 26 05:42:52 EDT 2009
On 25 Mar 2009, at 19:01, Jason T. Greene wrote:
> 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.
Makes sense, unless the semantics in mind are that locks are explicit
until an unlock, even past a transaction commit. Perhaps if you want
a set of keys locked over more than one tx. But that sounds like a
wacky use case to me. :-)
>
>
>
> 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
> _______________________________________________
> jbosscache-dev mailing list
> jbosscache-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosscache-dev
--
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/20090326/0c6f8eb8/attachment.html
More information about the jbosscache-dev
mailing list