[
https://issues.apache.org/jira/browse/CASSANDRA-5062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13593419#comment-13593419
]
Cristian Opris commented on CASSANDRA-5062:
-------------------------------------------
I see, it makes sense now. I thought read_max reads the last accepted round
instead of the last proposal for the current round.
That would be correct strictly from a paxos point of view but it still would
not give us the consistency in terms
of qourum commit that we desire
Consider the following case (note I'm omitting proposals and proposal numbers
as it's not relevant)
{code}
X Y Z
1. C0 C0 C0 //initial state committed R=0
2. A(R=1)< A(R=1)< //Z leads R=1
3. C1 //Z has majority with Y, commits locally but
fails to commit on Y and X
4. A(R=2)< A(R=2)< //Z leads R=2
5. C2 C2 //Z has majority with X, commits locally and
on X, but not on Y
6. A(R=3)< A(R=3)< //Z leads R=3
5. C3 //Z has majority with X, commits locally but
fails to commit on X and Y
{code}
Now state is X=C2, Y=C0, Z=C3
There's no commit quorum so to do a consistent read you'd probably have to
resolve all unfinished rounds.
To prevent that I think we should ensure a quorum is committed before we
proceed with the next round. Having the acceptor check it has the latest
round before accepting would achieve that.
You might say "do not commit locally until we commit to a quorum" but I fear
this can still lead to a similar situation
> 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
