[
https://issues.apache.org/jira/browse/CASSANDRA-5062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13531222#comment-13531222
]
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: 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
