safely resolving conflicts on read
aphyr at aphyr.com
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