[
https://issues.apache.org/jira/browse/CASSANDRA-5062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13588316#comment-13588316
]
Cristian Opris commented on CASSANDRA-5062:
-------------------------------------------
Zab is not Paxos just vaguely resembles it. Zab leader replicates a totally
ordered log of idempotent operations to ALL followers. It requires a quorum of
followers to acknowledge the write before committing on the leader, and then
commits on the followers. When leader fails, the new leader is the one that is
most up-to-date with the writes (highest log sequence number) so that one will
necessarily have all the committed writes (If it does not have the commit for a
particular write I believe it can assume it's been committed, I'm a bit unclear
on this point).
The new leader needs to fully synchronize all the replicas and establish a
quorum before writes can resume. That may introduce a small period of
unavailability.
At least in ZK I believe clients connect to a single replica and may be behind
the leader with reads but they will always see all the writes (including their
own since they're forwarded to leader and replicated back) in consistent order
> 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
