Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Sat, 23 Feb 2013 02:44:14 +0000 (UTC)
From: "Jonathan Ellis (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: <JIRA.12623764.1355412285561.327071.1361587454118@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=13584968#comment-13584968 ] 

Jonathan Ellis commented on CASSANDRA-5062:
-------------------------------------------

Paxos actually addresses this problem nicely.  The key thing that Paxos does that 2PC/3PC do not is, after accepting a proposal, participants will reply to future proposals from any coordinator with the highest-numbered (i.e., most recent) accepted proposal, which the coordinator will then resume progress on.  Thus, partitions cannot cause multiple operations to succeed independently.  

In our example, A and at least one of {B,C} have accepted the original proposal.  On partition, a new coordinator must have both B and C accept a new proposal for it to succeed, and thus will get a reply containing A's value.  The new coordinator must then commit A's value.

                
> 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