Return-Path: X-Original-To: apmail-cassandra-commits-archive@www.apache.org Delivered-To: apmail-cassandra-commits-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 96039E7FD for ; Sun, 24 Feb 2013 23:44:12 +0000 (UTC) Received: (qmail 18330 invoked by uid 500); 24 Feb 2013 23:44:12 -0000 Delivered-To: apmail-cassandra-commits-archive@cassandra.apache.org Received: (qmail 18300 invoked by uid 500); 24 Feb 2013 23:44:12 -0000 Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@cassandra.apache.org Delivered-To: mailing list commits@cassandra.apache.org Received: (qmail 18290 invoked by uid 99); 24 Feb 2013 23:44:12 -0000 Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 24 Feb 2013 23:44:12 +0000 Date: Sun, 24 Feb 2013 23:44:12 +0000 (UTC) From: =?utf-8?Q?Piotr_Ko=C5=82aczkowski_=28JIRA=29?= To: commits@cassandra.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Issue Comment Deleted] (CASSANDRA-5062) Support CAS MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/CASSANDRA-5062?page=3Dcom.atla= ssian.jira.plugin.system.issuetabpanels:all-tabpanel ] Piotr Ko=C5=82aczkowski updated CASSANDRA-5062: ------------------------------------------ Comment: was deleted (was: Another option is optimistic versioning and vector clocks: 1. Check for expected value and get its version vector. 2. Write the new value with the updated version. 3. Reread the value. If value and version matches, we got CAS. The problem I can see with this approach is that if we timeout in step 2. o= r 3. (e.g. no quorum), the new value might have been written, although we d= idn't get a CAS. I'm not sure how a big problem it is. ) =20 > 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 class= ic 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 cre= ated 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 administrato= rs For more information on JIRA, see: http://www.atlassian.com/software/jira