Sean, Thanks for the explanation.
One last follow up. During testing I noticed that when using if_not_modified against a test cluster with a node using the PB interface and the Ruby client, if the bucket had an n_val greater than the number of nodes, the put would fail with 'modified' error, even when you use a W, DW, and PW of 1. Presumably this is because the internal get performed by the if_not_modified check within Riak uses the default R value, which is quorum, so if the default n_val of 3 is used, it expect at least 2 replies, whereas there is only one node available. Thus the get will fail. While a failure may be expected in this situation, the fact that is comes back as a stale write error is confusing, as the data is not really stale. On Thu, Nov 8, 2012 at 10:48 AM, Sean Cribbs <s...@basho.com> wrote: > Elias, > > The resulting strategy of allow_mult=false and last_write_wins=false > (which is a simplification for developer-friendliness mostly): > > 1) Resolve differences using the vector clock first. > 2) If siblings still exist, return the one with the latest timestamp. > > So in a sense, it's a combination of vector-clock resolution and > resolution by timestamp. This might be ok if your write rate is small, > meaning that writes are unlikely to conflict; the upshot is that you > don't have to worry about resolution. However, in general we suggest > developers think about resolution strategies during development and > then use allow_mult=true in production.
_______________________________________________ riak-users mailing list riak-users@lists.basho.com http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
