cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sylvain Lebresne (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-5062) Support CAS
Date Wed, 27 Feb 2013 18:33:15 GMT

    [ https://issues.apache.org/jira/browse/CASSANDRA-5062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13588596#comment-13588596
] 

Sylvain Lebresne commented on CASSANDRA-5062:
---------------------------------------------

Let me first say that as far as I'm concerned, the priorities for this ticket should be:
# correctness (as in, it would be nice not to spend the next 4 years fixing corner cases).
# an implementation that doesn't make Cassandra's code some Frankenstein monster.

You'll note that being fast is not on this list. That doesn't mean I don't care about fast,
all other things being equal, faster is better. But I don't think we're targeting heavy use
of conflicting CAS, not at first at least. The typical use case we're targeting initially
is the one described by Jonathan, the unique user account creation problem. In that use case,
1) your application probably don't do much user creation check (comparated to the overall
cluster load at least) and 2) it's fairly easy to partition the problem so that your CAS will
rarely conflict (so Paxos failing at liveness is not a huge concern).

All that to say that I'd rather start with something as simple as possible, and consider optimisations
later (as Jonathan said, if we expose this as a CAS, we can switch the implementation later
if need be).

Now, for our use case, I do believe Paxos without optimisation (that does mean one complete
paxos per-CAS) is simpler than Zab (to be honest, I haven't look that much at Zab, but what
I've seen does seem more complicated in practice).  I'm aware of papers like http://www.cs.utexas.edu/~lorenzo/corsi/cs380d/papers/paper2-1.pdf
but their main difficulties are due to 1) multi-paxos (not what I'm suggesting) and 2) replicated
log grow (it's difficult for them for reasons that don't apply to us (we fully control the
data to which the replicated log applies)). Could be that I'm over-optimistic but...

Anyway, all that to say that I'm going to give a shot at prototyping a version with a simple
Paxos. I've tried to detail a concrete implementation a bit on paper and that doesn't sound
too bad, we'll see. But feel free to give a shot to Zab and see how that goes :)

That does lead me to a more mundane problem: how do we expose a CAS in CQL3 (thrift is simpler
as it happens)?

                
> 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

Mime
View raw message