On Feb 24, 2012, at 7:46 PM, Reid Draper wrote: > The problem is that amongst all replicas for a particular key, > operations are not serializable. Put another way, if there > are concurrent writes to three replicas, > there is no way to figure out a total ordering for the actions. > > It's also important to note that even when you set W=N > for a write, it's possible that 1 write could succeed > and 2 could fail. The succeeding write is _not_ "rolled back" > when this happens. The user will see an error message > that the write didn't succeed on all replicas.
Got it. I was unsure how "If-Unmodified-Since" and "If-None-Match" were implemented, but that makes sense given Riak's architecture. >> >> I'm not convinced that a CAS operation is inevitably subject to data races. >> There are proven techniques for avoiding races at the cost of latency, >> which is acceptable in certain situations. > Correct, but as far as I know, there is no way to build a CAS system > on top of the primitives provided by the Riak public API. You need > a point of serialization amongst all of the replicas (for a particular key), > which Riak does not provide, for availability reasons. I think a point of serialization is not needed here. It should be sufficient to add a new internal API for nodes to handle a two-phase commit, and then the transaction coordinator (running on whatever node you make the request to) can contain the logic to carry out the transaction. I totally understand that under the current architecture and exposed API's of Riak KV it is not possible. _______________________________________________ riak-users mailing list [email protected] http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
