[jira] [Commented] (CASSANDRA-5062) Support CAS

["Jonathan Ellis (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/CASSANDRA-5062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13544001#comment-13544001 ] 

Jonathan Ellis commented on CASSANDRA-5062:
-------------------------------------------

bq. The problem is if the update in step 3 times out: the next client to come along may not see the update.

It's actually worse than that, because even if the update succeeds at CL.ONE, the next client still may not see the update unless we read at CL.ALL.  (We can't just say "well, the write has to succed at QUORUM to call it a success," since even success to a single replica will eventually be hinted/repaired to the others.)

If we're willing to require all replicas to be up (or we fail the CAS with UAE), then I think we can address this as follows:

# acquire lock (lease)
# check for expected value
# until update succeeds, retry update and renew lease
# release lease

If we require the lease period to be over 2x the write request timeout (1x for the lease renewal itself, 1s for the client's update), then if the coordinator fails and his lease expires, the next CAS to acquire the lease will either:

- See the update (reading at CL.ALL)
- Or if not, it can assume that the update was dropped by the replicas dealing with overloaded queues

One wrinkle: we added auto-retry to local writes in CASSANDRA-4753 to prevent dropping of hints.

Anyway, I don't think requiring all replicas to be up is reasonable, but I include this in case it inspires something more useful.
                
> 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