[
https://issues.apache.org/jira/browse/CASSANDRA-5062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13586346#comment-13586346
]
Piotr Kołaczkowski commented on CASSANDRA-5062:
-----------------------------------------------
I was thinking for using Paxos to do the CAS thing, not for leader election.
For Paxos it is advised not to use several parallel proposers only for
performance reasons, not for correctness. So it should be actually easier to
implement than guaranteeing only one leader as you'd have to do for a
lock-based protocol. IMHO considering that paxos seems simpler to implement
than 2PC or 3PC.
I don't think using a lock-based protocol, assuming writes at level < CL.ALL,
is much simpler than Paxos. I have a feeling that if you start with an
assumption that you need to lock only quorum of replicas instead of all to
perform and update, you'll immediately hit all the same problems that led to
inventing Paxos.
> 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
