cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sylvain Lebresne (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-5062) Support CAS
Date Fri, 01 Mar 2013 09:01:20 GMT


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

View raw message