[
https://issues.apache.org/jira/browse/CASSANDRA-5062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13586394#comment-13586394
]
Cristian Opris commented on CASSANDRA-5062:
-------------------------------------------
So I guess what I'm proposing is similar to what Piotr said above: each CAS is
a round of Paxos.
With some cleverness this can be collapsed to Multi-Paxos.
Spinnaker does leader election with ZK precisely because they did not want to
implement Paxos themselves.
>From the paper, section 5: "The replication protocol has two phases: a leader
>election phase, followed by a quorum phase where the leader proposes a write
>and the followers accept it."
That is Multi-Paxos, with first phase (leader election) handled by ZK and
second phase being the steady state (propose/accept) with the actual
write/commit
> 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
