[
https://issues.apache.org/jira/browse/CASSANDRA-5062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13592677#comment-13592677
]
Sylvain Lebresne commented on CASSANDRA-5062:
---------------------------------------------
bq. C_current.timestamp needs to be exactly R-1
I don't think that's necessary. We never mix rounds, because all operation and
paxos state include the round number. If you're an acceptor that is behind and
some proposer that is also behind propose some value, then so be it (we're
still guarantee the proposer will learn the value that was decided). Paxos is
fine with a acceptor failing and recovering at any time, which is exactly what
this is about.
> 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
>
> Attachments: half-baked commit 1.jpg, half-baked commit 2.jpg,
> half-baked commit 3.jpg
>
>
> "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
