[
https://issues.apache.org/jira/browse/CASSANDRA-5062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13588015#comment-13588015
]
Jonathan Ellis commented on CASSANDRA-5062:
-------------------------------------------
bq. because election is only employed to establish a single proposer and then
2PC-like atomic broadcast is used
This is not correct for Paxos. (Not sufficiently familiar with ZAB to comment
there.) Leader election is an optimization to avoid conflicts from multiple
proposers from reducing performance; the leader still follows the full Paxos
algorithm when proposing, to prevent the kind of lost ack problem I described
above if the leader fails and is replaced. (See section 3 of "Paxos made
Simple.")
bq. use that to declare a leader; then, monotonically increasing numbered CAS
rounds would go through the leader, and could be accomplished via a simplified
2PC protocol (to avoid lost acks).
What does this 2PC-that-avoids-lost-acks look like? Because I'm very satisfied
that 2PC itself has this problem, so it's far from clear to me how you get
there by "simplifying" it.
> 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
