Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Fri, 5 Jul 2013 08:27:49 +0000 (UTC)
From: "Sylvain Lebresne (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: <JIRA.12651400.1370541182374.3150.1373012869141@arcas>
In-Reply-To: <JIRA.12651400.1370541182374@arcas>
References: <JIRA.12651400.1370541182374@arcas>
Subject: [jira] [Commented] (CASSANDRA-5619) CAS UPDATE for a lost race:
 save round trip by returning column values
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Sylvain Lebresne commented on CASSANDRA-5619:
---------------------------------------------

What I meant is that if we were to add that 'result' boolean, we would not return v=null when the row doesn't exist. So, the boolean would be what tell if the CAS applied or not. And if it's false, the rest of the result set is the current values for the columns with a condition. If there is nothing more, it means the row wasn't existing in the first place, if there is columns but with null values, the row does exist but has no value for those columns. 
                
> CAS UPDATE for a lost race: save round trip by returning column values
> ----------------------------------------------------------------------
>
>                 Key: CASSANDRA-5619
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-5619
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Core
>    Affects Versions: 2.0 beta 1
>            Reporter: Blair Zajac
>            Assignee: Sylvain Lebresne
>             Fix For: 2.0 beta 1
>
>         Attachments: 5619_thrift_fixup.txt, 5619.txt
>
>
> Looking at the new CAS CQL3 support examples [1], if one lost a race for an UPDATE, to save a round trip to get the current values to decide if you need to perform your work, could the columns that were used in the IF clause also be returned to the caller?  Maybe the columns values as part of the SET part could also be returned.
> I don't know if this is generally useful though.
> In the case of creating a new user account with a given username which is the partition key, if one lost the race to another person creating an account with the same username, it doesn't matter to the loser what the column values are, just that they lost.
> I'm new to Cassandra, so maybe there's other use cases, such as doing incremental amount of work on a row.  In pure Java projects I've done while loops around AtomicReference.html#compareAndSet() until the work was done on the referenced object to handle multiple threads each making forward progress in updating the references object.
> [1] https://github.com/riptano/cassandra-dtest/blob/master/cql_tests.py#L3044

--
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