Possibility of a CAS API
d at d2fn.com
Fri Feb 24 21:09:08 EST 2012
If you need CAS semantics, then coordinate that outside of riak. Any
check-then-act type of operation where atomicity is important is going to
leave some room for a data race in a system with the distribution semantics
of riak. Would suggest thinking about the problem in such a way that
handling of siblings is tolerant of duplicate writes and eventually the
correct value bubbles up to the readers. That or do the coordination of
unique indexes in something not dynamo shaped.
I can't say I'm intimately familiar with the work yet, but others have
prototyped/postulated consistency layers on top of riak (a la zab) that
might more closely match what you're trying to do. None of this is in a
released / supported version of riak to my knowledge though.
On Fri, Feb 24, 2012 at 4:41 PM, Armon Dadgar <armon.dadgar at gmail.com>wrote:
> As part of a new feature we are working on, we've run into
> a situation where it would be incredibly convenient to have a
> check-and-set (CAS) API for Riak KV. In short, we are trying to build
> a unique index of a bucket, using a second bucket which acts as a
> reverse index.
> The CAS API would operate in the same manner as a PUT, except it
> should take a "last vclock". The new value + last vclock are submitted
> to the responsible vnodes. The vnodes respond if the last vclock
> for the key matches the specified last value. If we get "r" nodes
> that the last value matches, then we should commit the write. This method
> is basically a two-phase commit.
> It would also be great if no-value sentinel could be specified to indicate
> the CAS should only succeed if there is not already a key. We need this
> to make sure uniqueness constraints are not violated.
> I wanted to gauge the interest from the community in something like this,
> and see if I could get thoughts from the Basho team on if this could be
> Best Regards,
> Armon Dadgar
> riak-users mailing list
> riak-users at lists.basho.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the riak-users