safely resolving conflicts on read

Aphyr aphyr at
Wed Nov 2 13:46:29 EDT 2011

On 11/02/2011 10:40 AM, Justin Karneges wrote:
> Thanks everyone for these replies (and also Aphyr, off-list).  It has helped me
> confirm my suspicions and sounds like I'm on the right track.
> For one of my keys, I am doing sort of a manual "last write wins" by having
> the reader sort siblings by timestamp, then by vtag, to deterministically
> select the same sibling every time.  The reason for keeping the other siblings
> around is they may contain the only references to other keys created along
> with them.  A separate cleanup process can then be sure to delete the referred
> keys before removing the siblings.  And of course the algorithm used to
> determine the winning sibling is shared by both the read function and the
> cleanup function.

We do something similar. A feed, for example, stores a list of keys 
pointing to feed items. In memory, I store "pending insertion" and 
"pending deletion" lists on a feed. At save time, a model callback saves 
the items pending insertion, and deletes any pending deletion.

The conflict resolution operator for a feed takes the union of all feed 
item keys, sorts them (to keep the most recent X) and truncates the 
list--storing all the truncated items in the pending-deletion list. This 
isn't perfect, but has acceptable probabilistic bounds for our use case.


More information about the riak-users mailing list