jeffpk at nphos.com
Tue Aug 2 10:40:32 EDT 2011
jon gave a much better and more detailed description, but fundamentally no
true lock is possible without an atomic test and set operation.
So far, of all the No Sql DBs I've looked at, only Mongo has that
On Sun, Jul 31, 2011 at 4:55 PM, Soren Hansen <soren at linux2go.dk> wrote:
> I've seen a couple of posts here and there on the subject of a locking
> mechanism for Riak, most notably:
> While it would only serve as an advisory locking mechanism, wouldn't a
> bucket with a reasonably high n, w and dw set equal to n, a
> deterministic naming scheme for the object being locked, and a locking
> algorithm such as:
> 1. PUT /locks/object_id
> If-None-Match: *
> Body: <some unique identifier for the client thread>
> 1a. If this fails, wait for a while, then try again.
> 1b. If it succeeds, proceed to 2.
> 2. The doc for If-None-Match says "this does not prevent concurrent
> writes; it is possible for the condition to evaluate to true for
> multiple requests if the requests occur at the same time." I'm not
> completely sure if n=w=dw protects me from concurrent writes (I'm not
> familiar with the locking semantics of a single riak instance).
> Anyway, if I'm in fact not protected, the next step is to read the
> value back to make sure we're actually the ones holding the key. If
> not, go back to step 1. If yes, proceed as planned.
> 3. Once you're done with the lock, just DELETE it.
> If this were really that simple, someone would have suggested it. So,
> what is this Riak rookie (i.e. I) missing?
> Soren Hansen | http://linux2go.dk/
> Ubuntu Developer | http://www.ubuntu.com/
> OpenStack Developer | http://www.openstack.org/
> riak-users mailing list
> riak-users at lists.basho.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the riak-users