understanding optimistic concurrency in Riak

Jeremiah Peschka jeremiah.peschka at gmail.com
Sun Oct 6 09:33:23 EDT 2013


Inline:

---
Jeremiah Peschka - Founder, Brent Ozar Unlimited
MCITP: SQL Server 2008, MVP
Cloudera Certified Developer for Apache Hadoop


On Thu, Oct 3, 2013 at 9:19 PM, Alex Rice <alex at mindlube.com> wrote:

> Just trying to paraphrase how I understand it from the Riak docs, plus
> helpful feedback from Jeremiah :) Please correct if I'm not really
> groking it!
>
> with allow_multi = false, the default setting
>
> - To achieve CAS* -ish behavior for updates, you can always send the
> vector clock with a Put. If it fails with a modified message, then you
> can retry on the client side. This is the  basic optimistic
> concurrency usage.
> - If you also set w = all on Puts then this is *almost* guaranteed to
> be a true global CAS operation.
> - The big exception mainly being extremely frequent writes for that
> key, plus some other edge cases.
>

You'll get as close as you can with Riak to some kind of CAS behavior.
Using if_not_modified for this behavior provides some limited guarantees,
but nothing global. As Reid points out in [1], it's possible for two actors
in your system to issue concurrent writes that both succeed while using
if_not_modified.

Basically, you can't really be sure about what's happening with this
behavior. Example:

UserA modifies their details and hits submit.
Details are sent to ServerA.
UserA spots a mistake, changes their zip code (this person is fast) and
hits submit again.
Details are sent to ServerB.

There are a number of amusing situations where the write from ServerB can
arrive at the same time as the write for ServerA and produce a result that
you may not want to see. When you're using siblings, you can at least add
additional information to the object you're persisting to help you resolve
siblings.

In busy systems, sibling resolution is the better option for dealing with
updates because it will provide consistent behavior under load, when writes
are being issued to different servers, and even when there is a partition
in Riak.

[1]: http://riak-users.197444.n3.nabble.com/if-not-modified-td4025937.html


>
> with allow_multi = true
>
> - You can still use the vector clock to get CAS-ish behavior as above.
> - You also have to resolve Sibings through client side logic each time you
> Get
> - It's *still* not guaranteed to be global CAS , there are special
> cases like hinted handoff, clock skew, gnarly stuff involving the
> speed of light etc.
>

Yup, there's no way to get any kind of CAS type behavior out of Riak, but
siblings are A-OK. I find them at lot easier to think about.


>
> * CAS = check and set
>
> _______________________________________________
> 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/20131006/5756eba1/attachment.html>


More information about the riak-users mailing list