cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Cristian Opris (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-5062) Support CAS
Date Wed, 27 Feb 2013 13:21:14 GMT


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

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:
>             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:

View raw message