[
https://issues.apache.org/jira/browse/CASSANDRA-5062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13588668#comment-13588668
]
Jun Rao commented on CASSANDRA-5062:
------------------------------------
To support things like CAS, the easiest way is for all writes to go to a leader
replica that orders all incoming writes. There are different approaches for the
leader to commit data. One approach is the quorum-based one used in Paxos, ZK
and Spinnaker. The advantage of this approach is that it can hide the latency
of a slow replica. The disadvantage is that for 2f+1 replicas, it only
tolerates f failures (instead of 2f failures). While this is ok for ZK since it
only stores state info, it's probably not ideal for systems that store real
data. For that reason, in Kafka, we designed a slightly different approach for
maintaining strongly consistent replicas. The details can be found in the
ApacheCon presentation that I gave yesterday
(http://www.slideshare.net/junrao/kafka-replication-apachecon2013). The Kafka
design doesn't do paxos, but depends on ZK for leader election. So, the
implementation is a bit simpler than that used in Spinnaker.
> 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
