[
https://issues.apache.org/jira/browse/CASSANDRA-5062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13591491#comment-13591491
]
Sergio Bossa commented on CASSANDRA-5062:
-----------------------------------------
I think we are deviating from the raw Paxos protocol in a number of ways.
Paxos is a consensus protocol to have distributed processes agree on *any*
value, meaning that a proposer is not bound to its own value, but our use case
is a bit different: the proposer is actually bound to its own value *and* the
latest accepted value, because the cas operation depends on both; it is true in
your sketch you eventually commit other higher proposals and return false, but
that's not enough, as there may be races between accept/commit phases.
In other words, Paxos has no commit phase as everything happens during accept;
the proposer sends the accept request, and the acceptors reply with ok/notok,
that's it: if it is not ok (meaning the accepted value came from another
proposer), and the proposer cares about its value to be accepted (our case!),
another round will have to start.
Reading/Learning the value happens at read time: a quorum read is issued and
the highest accepted proposal is taken (and if there's no quorum, it errors
out).
This implies the following to me:
1) Liveness is sacrificed, but we don't care (fair enough).
2) No need for the commit phase: everything happens during the accept phase.
3) No need for the op log: during fail-recovery, older proposals will be
discarded and the newest ones can just be "learnt" via a quorum read.
I just think we should track kind-of epochs for Paxos rounds, to avoid old
inflight (hinted?) rounds to "leak into" newer ones (or maybe the proposal uuid
is enough?).
This actually sounds simpler than Zab (our use case is pretty limited for now),
so I'm agreeing with the Paxos choice :)
Or am I missing something?
> 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
>
> Attachments: half-baked commit 1.jpg, half-baked commit 2.jpg,
> half-baked commit 3.jpg
>
>
> "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
