[
https://issues.apache.org/jira/browse/CASSANDRA-5062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13588542#comment-13588542
]
Cristian Opris edited comment on CASSANDRA-5062 at 2/27/13 5:32 PM:
--------------------------------------------------------------------
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 once 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.
was (Author: [email protected]):
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
