cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sergio Bossa (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-5062) Support CAS
Date Mon, 25 Feb 2013 21:36:15 GMT


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