Two questions about pre/post update hooks

Ryan Zezeski rzezeski at basho.com
Mon Jul 11 21:31:14 EDT 2011


Jeffery,

I'm going to assume by "update" you mean a read, modify, put cycle.  I'm
afraid what you're talking about doing is not directly supported by Riak.
 If you have multiple clients writing this object concurrently then there is
no way for Riak to guarantee that a conflict hasn't occurred.  That is,
there is no notion of locking the object and therefore two writes could
interleave each other and cause sibling values.  This is by design, and is
appropriately handled by setting allow_mult to true and performing conflict
resolution on your values.  If you wanted to serialize writes in this way
then you will have to do it your application.

Performing the validation in a pre-commit hook should be fine.  It's just
that Riak won't give you any form of isolation/locking among writes.  If
you're able to, perhaps you could share what you're trying to achieve?
 Maybe there is another way around the problem without requiring sequential
writes?

-Ryan

On Fri, Jul 8, 2011 at 1:18 PM, Jeffrey Kesselman <jeffpk at nphos.com> wrote:

> (1) AIUI a given key/value data pair is "owned" by a given node at one time
> and operations on it happen on that node and are then replicated out.  Is
> this correct?
>
> (2) Is the key/value pair "locked" between pre update and post update?
>
> The motivation for this question is this.
>
> I need to do the following operations on update:
>
> (1) In the pre-update hook, get the existing value (lets call it A)
> (2) Compare some data in the update (lets call it A') with A
> (3) Validate or reject the update based on that comparison
> (4) If validated, write A' out as the new value of A, if not, return a
> validation error.
>
> I need 1-4 to happen in a consistent fashion,  If someone else can come  in
> and update A after (1) but before (4), the scheme wont work.
>
> I *could* do my own locking in (1) and then add an unlock step in (5)
> assuming that all updates will take place on the same node, but I
> dislike injecting locking into a system that has unknown other expectations
> of the operation.
> --
> It's always darkest just before you are eaten by a grue.
>
> _______________________________________________
> 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/20110711/117ae3bb/attachment.html>


More information about the riak-users mailing list