Sent from my iPhone On Nov 6, 2012, at 7:34 PM, Reid Draper <reiddra...@gmail.com> wrote:
> Elias, > > There's quite a few questions in here, but hopefully I'll answer the meat of > what you're > trying to find out. Using `if_not_modified` is _not_ equivalent to a > distributed atomic > compare-and-swap (CAS). As you've correctly identified, concurrent writers > on different coordinators can all succeed in writing different values, while > still meeting the prerequisite for `if_not_modified`. Aye. I figured as much from previous discussion, but what the docs are not clear on is what other guarantees if-not-modified makes aside from concurrent writes. The docs fail to mention what R and PR, if any, are used to determine the current vclock for the if-not-modified check. When expect some guarantees, even if weak, or the feature would not exist. These to be made explicit. It's also not clear from the docs what Riak considers the latest value to return if allow_mult is false and so is last_write_wins, when you have a conflict. > > Reid > > On Nov 6, 2012, at 2:06 PM, Elias Levy <fearsome.lucid...@gmail.com> wrote: > >> The description of if_not_modified is lacking in the documentation. What >> guarantees if_not_modified provides is a question that has been asked in >> the list a few times, but for which no satisfactory answer has been given. >> Its something I've been wanted answered as well, so I did a bit of digging >> into the code. >> >> I gather from reading the code that whatever node receives the INM request >> perform an internal get to retrieve the object to get its vclock to compare >> to the incoming object. The get appears to use the R value that is the >> default for the bucket. The default value of R for a bucket is "quorum", >> unless changed, although the default for PR is 0. Thus, INM can strongly >> guarantee no stale writes, but only if no primary replica nodes have failed >> or have become partitioned. That also assumes that you are using at least >> an W of "quorum", and ideally a PR of the same. >> >> Correct me if I am wrong, but there appears no way to set the R and PR >> values to be used by the internal get during a INM put request, except for >> changing the bucket default R and PR values. >> >> The INM only guarantees no stale writes, and only does so when R, PR, W, and >> WR are such to to guarantee strong consistency. It does not guard against >> concurrent writes. Multiple writers can succeed even when using INM if they >> write at the same time. >> >> If you have allow_mult set to true in the bucket, that means the client must >> handle sibling resolution. If allow_mult is set to false and >> last_write_wins is set to true, concurrent writes will succeed, but the >> value with the latest timestamp will win. If last_write_wins is set to >> false while allow_multi is also false, Riak will keep siblings internally, >> but use vector clocks to only return a single value. >> >> Its unclear from the documentation what it does in the case of conflicts to >> resolve the siblings into the single value. The docs say you'll receive the >> "latest" value, but does not say how latest is determined in the case of a >> conflict. >> >> Elias Levy >> >> _______________________________________________ >> riak-users mailing list >> riak-users@lists.basho.com >> http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com > _______________________________________________ riak-users mailing list riak-users@lists.basho.com http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
