cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sylvain Lebresne (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-5062) Support CAS
Date Thu, 28 Feb 2013 18:27:15 GMT


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

bq. Ugly-ish, but what other options are there?

Well, we can perfectly return a result, something looking like:
k | c | cas(c, 3, 4)
0 | 1 | true
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:
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:
>             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:

View raw message