[
https://issues.apache.org/jira/browse/CASSANDRA-5062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13590344#comment-13590344
]
Sylvain Lebresne commented on CASSANDRA-5062:
---------------------------------------------
Paxos is use here to have replicas agree on basically the value post-next-cas.
I.e. a proposer proposes it's values as if the cas was ok. If the replica tell
us that our proposal (so our cas) don't win anyway, we bail out (which I don't
think is the right thing to do, but that's a detail for now), otherwise we
check our cas does indeed apply and we send accepts. Now, paxos guarantees
basically that once a majority of replica have accepted one value, only this
value can ever be accepted, even by other proposer.
So far, raw paxos only allow us to do one CAS (per row-key) ever. I.e. paxos
allows to agree on what is the first cas to go it but that's it. To be able to
continue, we need to restart a completely new instance of paxos. How does that
happen exactly in your sketch? I think you elude to that in you comment on the
commit phase with 3b, where you "discard acceptance records for successfully
committed replicas", which I understand more or less as, "once we've committed
the first paxos result, we forget all state and start afresh a new paxos
instance". But this is not obviously correct to me. At the very least, it seems
to me that you shouldn't start forgetting about the previous instance of Paxos
before you've make sure a majority of replica have learn about the commit
result.
So basically I don't understand how the commit part work and more generally how
do you go from one round to Paxos to the next (where by round, I mean a full
instance of the paxos algorithm) since you don't seem to formalize the notion
of round.
> 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
>
>
> "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
