riak-users Digest, Vol 42, Issue 3

Elias Levy fearsome.lucidity at gmail.com
Thu Jan 3 13:43:03 EST 2013

On Thu, Jan 3, 2013 at 9:00 AM, <riak-users-request at lists.basho.com> wrote:

> From: qaspar <snooper77 at gmail.com>
> Hi,
> Can someone confirm this? If it's true, what exactly is the purpose of
> offering the if_not_modified flag?
> Kaspar
The consistency guarantees of if_not_modified  depend on the default R
value configured on the bucket properties.  INM request perform an internal
from the node coordinating the request get to retrieve the object to get
its vclock to compare to the incoming object.  The get uses the R value
that is the default for the bucket.  The default value of R for a bucket is
"quorum", although the default for PR is 0.  Thus, by default INM strongly
guarantees no stale writes, but only if no primary replica nodes have
failed or have become partitioned.  This also assumes that you are using at
least an W of "quorum", and ideally a PR of the same.  If you change the
default bucket PR to "quorum", then it guarantee this also when primary
nodes fail or there is a partition, but it does this at the expense of

The INM only guarantees no stale writes, and only does so when R, PR, W,
and WR are such to to guarantee strong consistency.  It does not guard
against concurrent writes.  Multiple writers can succeed even when using
INM if they write at the same time.

If you have allow_mult set to true in the bucket, that means the client
must handle sibling resolution.  If allow_mult is set to false and
last_write_wins is set to true, concurrent writes will succeed, but the
value with the latest timestamp will win.  If last_write_wins is set to
false while allow_multi is also false, Riak will keep siblings internally,
but use vector clocks to resolve the siblings, and if that fails, fall back
on timestamp, to only return a single value.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.basho.com/pipermail/riak-users_lists.basho.com/attachments/20130103/190d965a/attachment.html>

More information about the riak-users mailing list