[
https://issues.apache.org/jira/browse/CASSANDRA-5062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13619268#comment-13619268
]
Jonathan Ellis commented on CASSANDRA-5062:
-------------------------------------------
bq. During prepare, if a replica "promise", the ballot it sends back in the
response is the one it just got
This is a bug, it's supposed to reply with the ballot of a previously accepted
value (so the coordinator can pick the highest such to re-propose).
bq. Why not just use a System table for the Paxos state?
I was hoping to avoid that, but you're right.
bq. Should that compare the timestamps of the UUIDs (The clock sequence is not
the timestamp). Furthermore, wasn't the goal to have a comparator to have it
only compare and timestamps (and thus not break tie on same timestamp)?
Yes, and yes.
bq. wasn't the goal to reuse the ballot timestamp as the timestamp of the
columns in the update we finally commit
I'm on board with that, but since we're generating ballots server-side that
means we need to swallow CASSANDRA-5293...
bq. I strongly believe we should return false only if the CAS doesn't apply,
but otherwise we should just restart a new proposal
I agree, but on the other hand "just retry automatically" is something that we
avoid elsewhere for good reason (arbitrarily high latency with no visibility to
the client what is going on). I also considered introducing a new exception
type explaining the state, but throwing an exception when everything is working
fine is also not intuitive. So I think all the options kind of suck, but this
one sucks least IMO.
Fixes pushed to the same branch.
> 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
