[ANN] Riak 2.0pre1

Eric Redmond eredmond at basho.com
Mon Jan 20 15:48:09 EST 2014

On Jan 20, 2014, at 12:35 PM, Elias Levy <fearsome.lucidity at gmail.com> wrote:

> On Mon, Jan 20, 2014 at 12:14 PM, Russell Brown <russell.brown at 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 at lists.basho.com
> http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.basho.com/pipermail/riak-users_lists.basho.com/attachments/20140120/9d4a76c8/attachment.html>

More information about the riak-users mailing list