[
https://issues.apache.org/jira/browse/CASSANDRA-5062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13627966#comment-13627966
]
Jonathan Ellis commented on CASSANDRA-5062:
-------------------------------------------
I was going to write that I'm still not a fan of "everything is a Commit"
approach, because the duplicated information in PaxosState and PrepareResponse
matches the semantics of what we are doing poorly -- it appears to imply that
different responses could be for different keys, or even have different keys
for the two Commits in PaxosState (or PrepareResponse). It also obfuscates
that prepare only cares about ballot.
But then I started adding cfid and we have the same problem at the ColumnFamily
level. So screw it, I welcome my new Commit overlord. But I'm adding some
asserts to make myself feel better.
Pushed cfid incorporation and TTL code to
https://github.com/pcmanus/cassandra/commits/5062-5.
(I think to start with using gcgs for TTL is fine.)
> 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
