Possibility of a CAS API
armon.dadgar at gmail.com
Sat Feb 25 20:46:05 EST 2012
On Feb 25, 2012, at 5:38 PM, Reid Draper wrote:
> 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.
Yes, that sounds correct. I think we are saying the same thing.
It certainly wouldn't be as performant as doing a non-CAS operation,
but for situations where you are willing to make that trade off, it would be nice to have support.
> It might be possible to do CAS with replicas without a synchronization
> point, but I imagine such a discovery would be publication-worthy.
Haha, indeed that would be.
More information about the riak-users