[
https://issues.apache.org/jira/browse/CASSANDRA-5062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13589756#comment-13589756
]
Sylvain Lebresne commented on CASSANDRA-5062:
---------------------------------------------
bq. We could throw an exception if the update is not a success.
The problem is, it only works if you only allow one CAS per update and nothing
else. And if we're going to have that kind of restriction, maybe it's just
simpler to have a specific CAS statement.
bq. Ugly-ish, but what other options are there?
Well, we can perfectly return a result, something looking like:
{noformat}
k | c | cas(c, 3, 4)
--------------------
0 | 1 | true
{noformat}
Though returning that from an UPDATE is probably not the best idea. But if we
add a specific statement for CAS, then it's perfectly OK to return that kind of
result.
Overall, I'm kind of leaning towards having a specific statement. Which could
look like say:
{noformat}
ATOMICALLY UPDATE foo IF c = 3 SET c = 4 WHERE ...
{noformat}
Though for the same reasons than above, we can't really allow that in a batch.
That's random ideas though, I just don't have a better one yet.
> 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
