[
https://issues.apache.org/jira/browse/CASSANDRA-5062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13593635#comment-13593635
]
Sylvain Lebresne commented on CASSANDRA-5062:
---------------------------------------------
bq. That could work
Not only it could work, but that's exactly what the pseudo-code in my document
does (I'm sorry to be rude, but I took the pain of writing 500 lines of
explanation/pseudo-code in a separate document to avoid "spamming" the JIRA
with my whole train of though. It would have been nice of you to make sure you
understand what's there before shooting a comment here every other minute,
because this will make it very hard to follow for other people interested in
the issue).
And I don't pretend my proposal can't be optimized, only that it's correct. But
truth being told, in practice, learn messages won't be lost randomly as in your
example, so I'm not even sure it's worth optimizing in practice (or that it
will be an optimization in the first place, "ensuring you always have a quorum
that has learned" during accept won't have 0 cost).
> 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
