[
https://issues.apache.org/jira/browse/CASSANDRA-5062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13592241#comment-13592241
]
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 http://goo.gl/pnq4Z, 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: https://issues.apache.org/jira/browse/CASSANDRA-5062
> 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 3.jpg
>
>
> "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
