Locking

Jon Meredith jmeredith at basho.com
Tue Aug 2 10:50:41 EDT 2011


Hi Jeffrey,

Do you know if Mongo provides locks that can be used on clusters of machines
and in the presence of network partitions/failures?  Riak could probably get
close if you created a cluster with a single node and performed all accesses
with N=R=W=1 as updating a single vnode is atomic, it's only when the order
of vnode requests can be interleaved that you get problems.  Of course you'd
have a single point of failure....

Soren: It may be worth looking at a separate lock service along the lines of
Zookeeper - you could take a look at the work Joe Blomstedt did on riak_zab
https://github.com/jtuple/riak_zab but as the FAQ suggests do not use it in
production.

BR,
Jon.

On Tue, Aug 2, 2011 at 8:40 AM, Jeffrey Kesselman <jeffpk at nphos.com> wrote:

> 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
> capability.
>
>
>
> 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:
>>
>>   http://riak-users.197444.n3.nabble.com/Riak-and-Locks-td1866960.html
>>
>> 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
>> http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
>>
>
>
> _______________________________________________
> riak-users mailing list
> riak-users at lists.basho.com
> http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.basho.com/pipermail/riak-users_lists.basho.com/attachments/20110802/bdf5fa99/attachment.html>


More information about the riak-users mailing list