Possibility of a CAS API
reiddraper at gmail.com
Sat Feb 25 20:38:10 EST 2012
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.
More information about the riak-users