cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Cristian Opris (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (CASSANDRA-5062) Support CAS
Date Mon, 04 Mar 2013 21:07:13 GMT

    [ https://issues.apache.org/jira/browse/CASSANDRA-5062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13592634#comment-13592634
] 

Cristian Opris edited comment on CASSANDRA-5062 at 3/4/13 9:05 PM:
-------------------------------------------------------------------

Sorry, I've probably edited my comment after your reply.

C_current.timestamp needs to be exactly R-1 if you increment the counter on sending the proposal.

If it's less, then the acceptor hasn't learned the previously committed value (R-1) so can't
participate in round R, otherwise we're mixing up rounds.

If it's more, then the proposer is behind so you already handle that.


Regarding " If you get quorum for the proposal you can perform the CAS locally and just
send the new column value with the accept"

By that I meant you can do the validate part of the CAS locally, not actually write the CAS.


Basically any operation (not just CAS) can be evaluated (in memory) by the proposal after
it gets quorum for the proposal (which guarantees it has the latest *committed* value) so
it obtains the value to send for acceptance. This is more of an optimization where you exchange
and agree on values rather than operations (state transfer replication). Also solves the problem
of where to validate the CAS.


                
      was (Author: onetoinfinity@yahoo.com):
    Sorry, I've probably edited my comment after your reply.

C_current.timestamp needs to be exactly R-1 if you increment the counter on sending the proposal.

If it's less than the acceptor hasn't learned the previously committed value (R-1) so can't
participate in round R, otherwise we're mixing up rounds.

If it's more, than the proposer is behind so you already handle that.


Regarding " If you get quorum for the proposal you can perform the CAS locally and just
send the new column value with the accept"

By that I meant you can do the validate part of the CAS locally, not actually write the CAS.


Basically any operation (not just CAS) can be evaluated (in memory) by the proposal after
it gets quorum for the proposal (which guarantees it has the latest *committed* value) so
it obtains the value to send for acceptance. This is more of an optimization where you exchange
and agree on values rather than operations (state transfer replication). Also solves the problem
of where to validate the CAS.


                  
> Support CAS
> -----------
>
>                 Key: CASSANDRA-5062
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-5062
>             Project: Cassandra
>          Issue Type: New Feature
>          Components: API, Core
>            Reporter: Jonathan Ellis
>             Fix For: 2.0
>
>         Attachments: half-baked commit 1.jpg, half-baked commit 2.jpg, half-baked commit
3.jpg
>
>
> "Strong" consistency is not enough to prevent race conditions.  The classic example is
user account creation: we want to ensure usernames are unique, so we only want to signal account
creation success if nobody else has created the account yet.  But naive read-then-write allows
clients to race and both think they have a green light to create.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Mime
View raw message