[
https://issues.apache.org/jira/browse/CASSANDRA-5062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13625923#comment-13625923
]
Jonathan Ellis commented on CASSANDRA-5062:
-------------------------------------------
bq. In SP.preparePaxos, if we throw if !mostRecentCommitHasQuorum and since
PrepareCallback only waits for quorum response
We wait for as many nodes as were alive at the start of the paxos request.
bq. I think it is necessary to re-prepare after the commits anyway because
those commit will erase the paxos state on the replica, so some of the promise
we got are not valid anymore.
We don't erase the promise, and we shouldn't, because that would allow us to
accept an out-of-date propose (that got delayed in the intertubes from another
proposer, for example -- does not require buggy proposers).
bq. So retrying server side seems to me like the right and the most efficient
one.
All right, although pushing the side effect back to the client also makes it
much less likely to race with a proposer that has interrupted us. Added some
sleep(0.100) to attempt to make this less problematic.
bq. When getting the prepare response, I think that as soon as we get a
response that is not promised, we can stop waiting for the other responses.
Agreed, but the logic to do this gets kind of ugly. Don't think it's worth
addressing.
bq. the timestamp of the columns we write during the commit should be the
ballot timestamp
What does this buy us? I don't think we need to allow mixing CAS/non-CAS on a
row, and it would make using non-clock-timestamps impossible.
bq. SystemTable.savePaxosCommit doesn't seem to delete in_progress_ballot
As above, this is deliberate.
bq. there is a bunch of places where we could reuse the new Commit class
I prefer to keep ballot/proposal separate except for the MRC since
promise/accept are done at different times.
> 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
