cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sylvain Lebresne (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-5062) Support CAS
Date Mon, 04 Mar 2013 14:41:16 GMT


Sylvain Lebresne commented on CASSANDRA-5062:

[~jbellis] Still a bit confused by your diagram really. Mainly, it seems from what's above
that your mostRecentCommitted is a Paxos proposal number, but then you seem to use it to decide
whether to move from one round to the other. So does that mean that what you call round in
those diagram is just a proposal number (in which case, I'm still confused on how you actually
use Paxos to do CAS) or does it means a full instance of the Paxos algorithm (in which case,
I haven't fully understood how you decide it's ok to start a new round without breaking correctness)?

All that to say, if you have some pseud-code of the whole things, I'd be interested :).

In the meantime, I've pushed my own reflection a bit too, fixing the impracticability I mention
earlier (of an ever growing log basically). I wrote the thing down to convince myself this
was working and get rid of foggy part. This is a largely a brain dump, though it does contain
a fairly precise algorithm that as far as I can tell, work (but I could definitively have
missed something). I put that brain at, in case that's of interest (it's
*not* short, but I think it's fairly precise). That proposal definitively share a number of
idea/similarity with Jonathan's one, but it's definitively not similar since it doesn't provide
the same tradeoff (it doesn't allow mixing CAS and non-CAS operation for one, and is not "rate
limited by clock resolution and clock skew", though I'm not sure what that means tbh). It's
fairly simple to implement too. Anyway, just wanted to share my own reflexion.
> Support CAS
> -----------
>                 Key: CASSANDRA-5062
>                 URL:
>             Project: Cassandra
>          Issue Type: New Feature
>          Components: API, Core
>            Reporter: Jonathan Ellis
>             Fix For: 2.0
>         Attachments: half-baked commit 1.jpg, half-baked commit 2.jpg, half-baked commit
> "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