cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jonathan Ellis (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-5062) Support CAS
Date Thu, 13 Dec 2012 17:34:13 GMT


Jonathan Ellis commented on CASSANDRA-5062:

I'm actually talking about the CAS operation assuming the locks work perfectly:

# acquire lock
# check for expected value
# proceed with update
# release lock

The problem is if the update in step 3 times out: the next client to come along may not see
the update.  In my account creation example, {{SELECT * FROM users WHERE username = X}} might
come back empty, but still have an {{INSERT}} winding through the system from a previous operation.

The obvious answer is, "don't release the lock until we know for sure the update succeeds,"
but that only works if we assume the client never fails once the lock is acquired.
> 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