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

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

bq. once the coordinator gets the acks from the prepare phase, it can commit 
without having to wait for all acks

What Jonathan means by lost ack is: what happens if when the coordinator sends 
the commits to replicas, but only a minority of replicas get that commit (say 1 
of 3 replica got it (and persist it), the two other dies between the prepare 
and commit phase). And later on, the 2 replica get back up while the 3rd one 
now dies, and we do a new CAS (that would have a majority and so should work).

In that case, probably the coordinator should hint something when he don't get 
the commit-ack from the 2 replicas that died. It could either try to revert 
from the 1 replica that did received the commit, but said replica can now be 
dead (playing devil's advocate here), so it might be a hint really. Or we rely 
on the commit being hinted to the 2 died replica when they come back up. But in 
that any case, replicas would need to check and wait for those hints when they 
come back up before joining the ring, and that's a problem (any other node 
could have hint, we don't want to wait for everyone).

To be clear, I'm not saying Zab doesn't work or anything like that, just 
explaining the lost-ack problem we have identified with a naive 2PC 
implementation.
                
> 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
>
>
> "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