documentation for allow_mult=false

Tuure Laurinolli tuure.laurinolli at
Thu Nov 3 04:50:17 EDT 2011

On Nov 2, 2011, at 17:18 , Ryan Zezeski wrote:

> On Tue, Nov 1, 2011 at 5:51 PM, Justin Karneges <justin at> 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"

And what happens when you read two different values for the same key?

> 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)

Picking most recent write happens at read time, right? What if vector clocks don't provide order for the writes that were read? Do you still get siblings (IIRC I read this somewhere, but it might have been some other database)?

Assume N=3, W=2, R=2. What happens when clients A and B read value Vinit for key K, change it to values Va and Vb respectively, and then store the values? Presumably both stores succeed, and the database is in inconsistent state. How is this resolved, since there is no order for Va and Vb?

> 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

Here the end result is clear, both Va and Vb would be stored, and it would be up to the reader to decide which one is good.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the riak-users mailing list