cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sylvain Lebresne (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-5062) Support CAS
Date Mon, 04 Mar 2013 20:03:14 GMT

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

Sylvain Lebresne commented on CASSANDRA-5062:
---------------------------------------------

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

Note sure I follow. On the acceptor, if C_current.timestamp() < R, then it means the message
if for a round that hasn't been decided yet (more precisely, that we haven't learned out).
That's the case where we actually do some work (as the pseudo-code does really).

bq. Also note you don't need to send the column values with proposal

Not true. Even if a proposer has his value "accepted", there is not guarantee that it will
be the one learning it, or even the only one learning it for that matter. For a given round,
the value is decided as soon as a quorum of acceptor accepts it basically, irrelevant of whether
the original proposer of that value gets the commit acks or not. 

bq. Essentially consensus is on the next column value to write

Yes. As as discuss later in my brain dump, we'd likely want to support normal inserts at least.
The actual operation is largely of irrelevant (that's why it's a blob in the paxos_state table
:)). 
                
> 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