[ https://issues.apache.org/jira/browse/CASSANDRA-5619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13701874#comment-13701874 ]
Sylvain Lebresne commented on CASSANDRA-5619: --------------------------------------------- So using exceptions for this actually has some practical backward compatibility problem: we can't really add a new exception to the native protocol v1. And unfortunately there isn't an existing exception that would work very well. It's also a problem for CQL-over-thrift: while we can add a new exception in thrift, having it potentially returned by execute_cql3_query() is a breaking change. It's not necessarily a blocker, we can decide that CAS are only available with the native protocol v2 (and raw thrift), but it's a bit of shame. > 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: 0001-Add-back-boolean-result-column.txt, > 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