Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Wed, 27 Feb 2013 16:51:14 +0000 (UTC)
From: "Sergio Bossa (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: <JIRA.12623764.1355412285561.351102.1361983874632@arcas>
In-Reply-To: <JIRA.12623764.1355412285561@arcas>
References: <JIRA.12623764.1355412285561@arcas>
Subject: [jira] [Commented] (CASSANDRA-5062) Support CAS
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Sergio Bossa commented on CASSANDRA-5062:
-----------------------------------------

[~jbellis]:

{quote}if the leader reports success to the client after local commit, but before it has been committed to the followers, we could either (1) lose the commit on failover if followers are pessimistic, or (2) commit data that we originally reported failed{quote}

Nope, once the commit is reported as successful, even if still not acked, it will be always seen by clients because:
1) If the leader fails, the failed over one is guaranteed to see up to the latest (proposed or committed) value, because that's the way it is elected.
2) The only case when a commit can fail happens when the prepare phase doesn't get a quorum, but in this case the leader will have to retry until it gets it, times out or fails; last two options do not mean to the client the commit has failed, just that it has to retry (I think the same would be with Paxos, as the client is never part of the consensus).

This is really Zab/ZK by the way, I'm not adding much to it :)
                
> 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