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(a)ngc.com&gt; >>>>>> To: Bela Ban <belaban(a)yahoo.com&gt; >>>>>> CC: <javagroups-users(a)lists.sourceforge.net&gt; >>>>>> References: <0E36CF63779A934D876C5E7FD29E74EB01FA4FFC(a)XMBIL123.northgrum.com >>>>>> > <49C206DC.8030608(a)yahoo.com&gt; >>>>>> >>>>>> >>>>>> >>>>>> 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(a)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(a)jboss.org >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> -- >>>> Bela Ban >>>> Lead JGroups / Clustering Team >>>> JBoss - a division of Red Hat >>>> >>> >>> -- >>> Manik Surtani >>> Lead, JBoss Cache >>> http://www.jbosscache.org >>> manik(a)jboss.org >>> >>> >>> >>> >>> >> -- Jason T. Greene JBoss, a division of Red Hat _______________________________________________ jbosscache-dev mailing list jbosscache-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jbosscache-dev