[
https://issues.apache.org/jira/browse/CASSANDRA-5062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13587322#comment-13587322
]
Jonathan Ellis commented on CASSANDRA-5062:
-------------------------------------------
The thing that is stopping me from hacking together a Paxos prototype is, where
do we store the accepted-but-not-committed proposals? Sticking them on the
"end" of the row data in an sstable would be ugly. Ignoring it and saying
"paxos proposals have to fit in memory" is attractive, but then we can't remove
commitlog segments until each proposal is committed or overridden.
(Timing out accepted proposals and discarding them would put us back in the
"lost ack" problem space; we could commit multiple, conflicting proposals
during a network partition at the "right" time.)
> 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
