[
https://issues.apache.org/jira/browse/CASSANDRA-5062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13627973#comment-13627973
]
Sylvain Lebresne commented on CASSANDRA-5062:
---------------------------------------------
bq. should we allow propose/commit to accept ballots newer than the one it has
promised
That comment made me realize that at least for the commit part, my patch was
assuming that we were pretty much always accepting commits, so it was slightly
broken. So I've pushed one more commit on the branch to fix that. Hopefully
that makes sense. I note that I just saw your last push and that last commit is
not on top of that but rather on top of my earlier v5. Maybe you can just
cherry-pick that last commit?
For the propose, I think accepting newer-than-promised ballot would be ok, yes.
The promise made during prepare is to not accept anything older than the ballot
we promise to, but accepting something newer should be fine.
> 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
