On 20 Jan 2014, at 20:35, Elias Levy <[email protected]> wrote:
> On Mon, Jan 20, 2014 at 12:14 PM, Russell Brown <[email protected]> wrote: > Longer answer: Riak gave users the option of client or _vnode_ ids in version > vectors. By default Riak uses vnode ids. Riak erred on the side of caution, > and would create false concurrency, rather than lose writes. > > I am curious as to how that was accomplished when using vnode version > vectors. As section 3.2 of the paper mentions, the node with concurrent > updates could detect they are concurrent and it could reject the update, but > how could you encode the causal history using the version vectors so as to > generate a sibling? That section ends with a statement saying no such > version vector could be generated. > > Presumably Riak implemented a version vector that is somewhat different from > that described in the paper? I guess you must be right. Riak’s vnode version vectors, in the case described in 3.2 would generate siblings. The put of `v` with an empty VV would lead to the value `v` and VV {b, 1}, but the put of `w` with no VV would not lead to a VV of {b, 2} and overwriting of {b, 1}=`v`. What Riak does is this: look at the incoming VV, and increment it (so {b, 1}=`w` for that second client put) read the state on disk ({b, 1}=`v`) realise that these values are concurrent (the incoming value does not dominate the local value), so keep them both, and generate a VV that dominates ({b, 2}=`v`, `w`). Does that answer your question? Cheers Russell >
_______________________________________________ riak-users mailing list [email protected] http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
