incubator-cassandra-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sandeep Tata <sandeep.t...@gmail.com>
Subject Re: [jira] Commented: (CASSANDRA-48) test-and-set
Date Fri, 03 Apr 2009 16:30:56 GMT
This is very interesting: an eventually consistent system provides an
eventually consistent test-and-set :-)
If my semantics is that test-and-set succeeds if a majority return
success, the resolution rule here cannot be "latest timestamp wins".
It has to be a "majority wins".

A fails, B & C succeed = success. The value on A is inconsistent with
the "truth". Local reads on 'A' will return an invalid value. Strong
read to fix it.

The more interesting case is when one of the replicas is down. How can
you do a hinted handoff with the test-and-set ?
Hmm, I don't remember -- when we do a strong read, do we have a way to
grab any hinted-handoff-ed values ?

On Fri, Apr 3, 2009 at 9:18 AM, Jonathan Ellis <jbellis@gmail.com> wrote:
> That makes sense.
>
> In that case you would have to do a read that waits for all replicas.
> Which will hurt availability but I don't see any alternative.
>
> Again, this isn't intended going to provide strong consistency.  You
> can still come up with failure scenarios where inconsistent data could
> be read temporarily.  I'm not sure if it's going to be useful given
> that.
>
> On Fri, Apr 3, 2009 at 10:10 AM, Sandeep Tata <sandeep.tata@gmail.com> wrote:
>> Well, the test and set failed could have failed because of a new value
>> replacing the old one since this client read it.
>> Jun is talking about re-reading to get this new value and retrying the
>> "transaction"
>>
>> On Fri, Apr 3, 2009 at 9:08 AM, Jonathan Ellis (JIRA) <jira@apache.org> wrote:
>>>
>>>    [ https://issues.apache.org/jira/browse/CASSANDRA-48?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12695470#action_12695470
]
>>>
>>> Jonathan Ellis commented on CASSANDRA-48:
>>> -----------------------------------------
>>>
>>> The client should not do that.  It knows the old version (or it couldn't be
doing test-and-set) and it knows the new version and it knows that not all replicas were written
but some were.  Doing a read cannot possibly tell it anything it doesn't already know.
>>>
>>>> test-and-set
>>>> ------------
>>>>
>>>>                 Key: CASSANDRA-48
>>>>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-48
>>>>             Project: Cassandra
>>>>          Issue Type: Improvement
>>>>            Reporter: Jonathan Ellis
>>>>
>>>> Atomic test-and-set insert operation would be nice: "set value to X but only
if the current value is still Y."  This allows a sort of optimistic consistency: perform
a GET, then perform test-and-set with the value of that GET as Y.
>>>> I do not think that this requires strong consistency to be useful.
>>>
>>> --
>>> This message is automatically generated by JIRA.
>>> -
>>> You can reply to this email to add a comment to the issue online.
>>>
>>>
>>
>

Mime
View raw message