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. _______________________________________________ riak-users mailing list [email protected] http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
