[
https://issues.apache.org/jira/browse/CASSANDRA-5062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13586312#comment-13586312
]
Sergio Bossa commented on CASSANDRA-5062:
-----------------------------------------
Not sure Paxos is a good idea.
Complexity of the implementation apart (no wonder it is very hard to find a
good one around), I think we cannot use it to efficiently handle CAS: Paxos
rounds get expensive with several parallel proposers (i.e., several parallel
user creations), which is (one of) the reasons why many end up using Paxos only
for leader election (i.e., ZK uses a Paxos-like protocol in recovery mode, and
then simple 2PC for broadcasting values).
So, if using Paxos only for leader election, why not using a simpler protocol,
possibly lock-based (I know, old fashioned, but let's remember CAS is not the
main Cassandra thing)?
I may be missing something, or maybe making things too complex, or maybe I'm
still jetlagged, so feel free to object :)
> 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
