[
https://issues.apache.org/jira/browse/CASSANDRA-5062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13590519#comment-13590519
]
Jonathan Ellis commented on CASSANDRA-5062:
-------------------------------------------
bq. To be able to continue, we need to restart a completely new instance of
paxos.
Yes, that's the tricky part, and none of the papers go into detail here. I
think the outline here will work, but I'm open to better ideas.
bq. At the very least, it seems to me that you shouldn't start forgetting about
the previous instance of Paxos before you've make sure a majority of replica
have learn about the commit result.
"Commit" means "write it to the 'main' CF, update mostRecentCommitted, and
discard the proposal records." (Prepare/Accept/Commit are all commitlog'd;
normal caveats apply if you don't run with Batch mode.)
I think you're correct that we need to wait for a majority to agree on
mostRecentCommitted before proceeding.
> 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
