On Feb 25, 2012, at 8:29 PM, Armon Dadgar wrote: > On Feb 25, 2012, at 5:24 PM, Reid Draper wrote: >>>>> >>>>> 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. > > Not a global point of serialization, other transactions would be unaffected. > It is my understanding that there is a new transaction coordinator for > each client request. So it is already always "serial" in a sense.
What I'm suggesting you need is a point of serialization for at least a quorum of the replicas for a particular key. It doesn't have to be global across the key-space. It might be possible to do CAS with replicas without a synchronization point, but I imagine such a discovery would be publication-worthy. _______________________________________________ riak-users mailing list [email protected] http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
