documentation for allow_mult=false

Justin Karneges justin at affinix.com
Wed Nov 2 13:06:35 EDT 2011


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




More information about the riak-users mailing list