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 19:49:14 GMT

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

Cristian Opris edited comment on CASSANDRA-5062 at 3/4/13 7:48 PM:
-------------------------------------------------------------------

[~slebresne] I have read your pseudo-code, seems pretty much what I was trying to describe
with the version counter that counts paxos rounds (except I was thinking at row level rather
than column level)

I noticed however that while the leader's proposal is aborted if it has a stale round, the
acceptor algorithm does not handle the case when the 
acceptor replica is behind.

Basically in the acceptor algorithm you don't seem to handle the case where C_current.timestamp()
< R

One way to do that is to nack the proposal indicating it needs to catch up and either expect
to receive a "snapshot" from the leader or do a read.

Also note you don't need to send the column values with the proposal. If you get quorum for
the proposal you can perform the CAS locally and just
send the new column value with the accept

Essentially consensus is on the next column value to write, not the CAS. Since proposer is
guaranteed to be up to date before sending accept, 
it can do the CAS locally. 

                
      was (Author: onetoinfinity@yahoo.com):
    [~slebresne] I have read your pseudo-code, seems pretty much what I was trying to describe
with the version counter that counts paxos rounds (except I was thinking at row level rather
than column level)

I noticed however that while the leader's proposal is aborted if it has a stale round, the
acceptor algorithm does not handle the case when the 
acceptor replica is behind.

Basically in the acceptor algorithm you don't seem to handle the case where C_current.timestamp()
< R

One way to do that is to nack the proposal indicating it needs to catch up and either expect
to receive a "snapshot" from the leader or do a read.

Also note you don't need to send the column values with proposal. If you get quorum for the
proposal you can perform the CAS locally and just
send the new column value.

Essentially consensus is on the next column value to write, not the CAS. Since proposer is
guaranteed to be up to date before sending accept, 
it can do the CAS locally. 

                  
> 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