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

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

bq. But I don't think keeping the last commit value fixes this for the general 
case

What I had in mind was that on result of the prepare, we would wait for a 
quorum of people agreeing on the last MRC (i.e. a quorum has learn the last 
value) before allowing to proceed with our own value. Provided we always ensure 
that, then we can ensure that for every column in a CAS, then in any quorum at 
least one node has seen the last update for that column. However, if we don't 
do anything more, we may not be able to make progress, because if for a quorum 
of 2, the answer we get from a prepare is say MRC=t2 from node A and some very 
old state from node B, then we can't proceed because we don't have a quorum 
agreeing on t2 MRC, but we can't make progress either because we don't know how 
to bring B to MRC=t2. But if A had sent the most-recent-committed value 
corresponding to t2, then we could repair B (making it learn basically) and 
then start again the algorithm (we can even optimize a bit by sending the 
repair in the same message than the new prepare). Note that B might have missed 
more than the last commit, but as long as we make sure a QUORUM learn the value 
of every round before proposing, we're good.
                
> 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

Reply via email to