[
https://issues.apache.org/jira/browse/CASSANDRA-5062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13588328#comment-13588328
]
Cristian Opris commented on CASSANDRA-5062:
-------------------------------------------
On the other hand Paxos for each CAS would be quite different.
The basic approach would be to have each CAS be a full Paxos round (Phase 1:
prepare/promise, Phase 2: propose/accept). In this case each round is
independent and writes can happen concurrently (as opposed to Zab where all
writes are applied serially cluster-wide).
There doesn't even need to be a leader, that is an optimisation to ensure
liveness (avoid duelling proposers).
Now since full Paxos is quite expensive in terms of roundtrips, there are
optimisations to reduce that (see Fast Paxos in the wikipedia article) but I
have yet to study the details of that.
There is also the question of how the actual CAS op would be integrated with
Paxos (who does the CAS ? presumably the proposer needs to be able to do the
CAS verify locally, or maybe acceptors can NACK if the CAS is rejected locally
? Would that be a valid nack in Paxos terms ?) but that can be sorted out.
> 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
