You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cassandra.apache.org by Sandeep Tata <sa...@gmail.com> on 2009/04/03 18:10:47 UTC
Re: [jira] Commented: (CASSANDRA-48) test-and-set
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) <ji...@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.
>
>
Re: [jira] Commented: (CASSANDRA-48) test-and-set
Posted by Sandeep Tata <sa...@gmail.com>.
PNUTS, of course, solves this by mastering the record at some node
(leader election with ZK?) and walking away from hinted-handoff.
On Fri, Apr 3, 2009 at 9:33 AM, Jonathan Ellis <jb...@gmail.com> wrote:
> On Fri, Apr 3, 2009 at 10:30 AM, Sandeep Tata <sa...@gmail.com> wrote:
>> Hmm, I don't remember -- when we do a strong read, do we have a way to
>> grab any hinted-handoff-ed values ?
>
> no.
>
Re: [jira] Commented: (CASSANDRA-48) test-and-set
Posted by Jonathan Ellis <jb...@gmail.com>.
On Fri, Apr 3, 2009 at 10:30 AM, Sandeep Tata <sa...@gmail.com> wrote:
> Hmm, I don't remember -- when we do a strong read, do we have a way to
> grab any hinted-handoff-ed values ?
no.
Re: [jira] Commented: (CASSANDRA-48) test-and-set
Posted by Sandeep Tata <sa...@gmail.com>.
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 <jb...@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 <sa...@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) <ji...@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.
>>>
>>>
>>
>
Re: [jira] Commented: (CASSANDRA-48) test-and-set
Posted by Jonathan Ellis <jb...@gmail.com>.
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 <sa...@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) <ji...@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.
>>
>>
>