On Wednesday, November 02, 2011 08:18:48 AM Ryan Zezeski wrote:
> 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.
Thanks for this clear explanation of the allowed settings. This confirms that
allow_mult=false + last_write_wins=false indeed has its own behavior compared
to other configurations.
If you recall from my original email, I had a table with that entry missing.
We can now complete it:
allow_mult, last_write_wins
-----------
false, false -> {write siblings, magically read single values}
true, false -> write siblings, read siblings
false, true -> writes overwrite existing, read single values
true, true -> invalid
> 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.
Yes, they do seem like the same thing to me. Are you saying that with
allow_mult=false + last_write_wins=false, you could end up with a winning
write that occurred earlier than a losing write?
It would be great to see an explicit example of conflict resolution in this
scenario.
Justin
_______________________________________________
riak-users mailing list
[email protected]
http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
