documentation for allow_mult=false

Ryan Zezeski rzezeski at basho.com
Wed Nov 2 11:18:48 EDT 2011


On Tue, Nov 1, 2011 at 5:51 PM, Justin Karneges <justin at affinix.com> wrote:

> Are you saying that allow_mult=false + last_write_win=false is the same as
> allow_mult=false + last_write_win=true ?
>
> False/false may be the default behavior, but I want to know what that
> behavior
> is. :)
>
>
Justin,

No, last_write_wins=true doesn't care about the value of allow_mult.  Only
one should be true at the same time, and the default is to have both set to
false.  Perhaps making an imaginary setting to displace these two would
help.  Lets call this imaginary setting "conflict_resolution_method" which
can take on the three mutually exclusive values "stomp", "most_recent" and
"siblings".

stomp - overwrite the current value with the new value regardless of vector
clocks, just mutate the value with no regard, thus "stomp"

most_recent - use vclocks to monitor for conflicts, create siblings, and
pick the most recent write when a conflict does occur (i.e. let Riak handle
the conflict for you based on time)

siblings - use vclocks to monitor for conflicts, create siblings, and
return the siblings to the client when a conflict occurs for it to be
resolved by some application dependent logic

Now lets map my imaginary field to the actual fields

stomp = last_write_wins=true + allow_mult=false

most_recent = last_write_wins=false + allow_mult=false

siblings = last_write_wins=false + allow_mult=true

Notice that setting both to true has undefined semantics as they
are necessarily mutually exclusive.

Also notice that stomp and most_recent might seem like the same thing on
the surface but they may have different outcomes in different situations.
 For example, stomp would prove to be non-deterministic during the healing
of a split-brain because it will depend on the order of the hinted handoff
transfers.  Honestly, you're best avoiding last_write_wins at this point
because it can cause non-obvious behavior and there is potential it may be
removed in the future.

HTH,
-Ryan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.basho.com/pipermail/riak-users_lists.basho.com/attachments/20111102/f158cb5f/attachment.html>


More information about the riak-users mailing list