cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jonathan Ellis (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-5062) Support CAS
Date Mon, 08 Apr 2013 22:46:18 GMT


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:
>             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
> "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:

View raw message