[
https://issues.apache.org/jira/browse/CASSANDRA-5062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13588542#comment-13588542
]
Cristian Opris commented on CASSANDRA-5062:
-------------------------------------------
In the Zab paper in 4.1 it says ??"We are able to simplify the two-phase commit
protocol because we do not have aborts; followers either acknowledge the
leader’s proposal or they abandon the leader. *The lack of aborts also mean
that we can commit once a quorum of servers ack the proposal rather than
waiting for all servers to respond.* This simplified two- phase commit by
itself cannot handle leader failures, so we will add recovery mode to handle
leader failures."??
So basically one a proposal is acked by a quorum there is no going back (no
abort). The leader has to succeed in committing that or else it will lose its
leadership.
If the client times out in the meantime it has to retry and find out what the
result was. Presumably this can happen with regular ACID databases as well,
where a client sends COMMIT TX and times out immediately after that.
> 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
