On Feb 25, 2012, at 8:18 PM, Armon Dadgar wrote: > 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. If I understand you correctly, the "transaction coordinator" would be a point of serialization. > > 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
