On Jan 20, 2014, at 12:35 PM, Elias Levy <fearsome.lucid...@gmail.com> wrote:
> On Mon, Jan 20, 2014 at 12:14 PM, Russell Brown <russell.br...@me.com> 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. The paper is correct. A sibling is generated when no such causal history can be discovered. If a causal history is found, there's no need for a sibling. In short, a sibling is a way to keep both values, this side-stepping the even worse scenario of rejecting (losing) a write. > Presumably Riak implemented a version vector that is somewhat different from > that described in the paper? > > _______________________________________________ > 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
