[
https://issues.apache.org/jira/browse/CASSANDRA-5062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13592743#comment-13592743
]
Cristian Opris commented on CASSANDRA-5062:
-------------------------------------------
Say you have this:
Proposer has committed R-1, starts round R, proposal timestamp Tn
Acceptor recovers with committed R-n < R-1, and has accepted value A at R-n+1 <
R-1 at Tm in the paxos state log.
When Acceptor receives proposal, if it doesn't check R, if Tm > Tn (clock
mismatch) according to paxos it needs to send it's old accepted value and the
proposer will have to use it to commit. It will end up committing an old value.
It's an edge case but not impossible. Paxos holds within the same round, but
not across rounds.
This makes sense because a Paxos round just means agree on a value which once
accepted by a quorum
can never change.
Which is why you can't have an out of date replica participate in a round.
The idea is to move from quorum that committed (learned) R to quorum that
accepts R+1 to quorum that commits R+1 and so on. Note the quorums don't need
to be made of same components.
To ensure this you maintain the invariant that *you can't propose or accept R+1
locally if you haven't committed R*
So a replica can die and recover, but to recover and participate in paxos needs
to learn the latest value.
This also gives you consistent read (at the possible cost of an extra read
paxos proposal to ensure that the last paxos round is committed if left
ambiguous)
> 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
