Clarifying "Read-before-Write"

Andres Jaan Tack andres.jaan.tack at eesti.ee
Fri Nov 25 20:14:13 EST 2011


So I was just reading and thinking about this, and I don't understand the
advice offered under "Read-before-Write" at
http://wiki.basho.com/Client-Implementation-Guide.html.

"Riak will return an encoded vector
clock<http://wiki.basho.com/Vector-Clocks.html>
>  with every "fetch" or "read" request that does not result in a "not
> found" response. In addition to the Client ID, this vector clock tells Riak
> how to resolve concurrent writes, essentially representing the "last seen"
> version of the object to which the client made modifications. In order to
> prevent sibling explosion<http://wiki.basho.com/Vector-Clocks.html#Sibling-explosion>,
> clients should always have a vector clock before sending a write, and send
> the vector clock as part of the write request. Therefore, it is essential
> that keys are fetched before being written (except in the case where Riak
> selects the key or there is *a priori* knowledge that the key is new).
> Client libraries that make this automatic will reduce operational issues by
> limiting sibling explosion. Clients may also choose to perform automatic Sibling
> Resolution<http://wiki.basho.com/Client-Implementation-Guide.html#Sibling-Resolution>
>  on read."


I'm having trouble understanding the advice. I get that if I'm aware of all
the siblings, I can resolve them (optionally) with that vector clock. What
I don't understand here: If an application PUTs to an object out of the
blue, not having read it first, should the client library
read-before-write? This seems like a great way to blow away siblings by
accident.

I'm having trouble understanding the advice. I get that if I'm aware of all
the siblings, I can resolve them (optionally) with that vector clock. What
I don't understand here: If an application PUTs to an object out of the
blue, not having read it first, should the client library
read-before-write? This seems like a great way to blow away siblings by
accident.

Or is the point rather to avoid sibling explosion for applications that
don't care about losing information?

--
Andres
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.basho.com/pipermail/riak-users_lists.basho.com/attachments/20111126/7f131315/attachment.html>


More information about the riak-users mailing list