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 <[email protected]> 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 > [email protected] > http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com >
_______________________________________________ riak-users mailing list [email protected] http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
