[
https://issues.apache.org/jira/browse/CASSANDRA-5062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13584966#comment-13584966
]
Jonathan Ellis commented on CASSANDRA-5062:
-------------------------------------------
Another approach is 2PC:
# Coordinator proposes a new value to replicas
# Live replicas reply that they have accepted the value and are ready to commit
# If a majority of nodes accept, Coordinator commits the new value to replicas
# Replicas acknowledge the commit; the operation is successful if a majority of
replicas acknowledge it
The problem here is dealing with partitions between steps 2 and 3. Suppose we
have three replicas, and have arrived at the beginning of step 3. The
coordinator issues the commit message, but only replica A receives it.
Replicas B and C are partitioned away, and can potentially participate in a new
quorum and commit a different value.
This is okay as far as it goes -- the original coordinator, that committed to
A, never saw an ack quorum for the commit, and so would have had to return a
TOE to the client. So we haven't broken our contract that exactly one client
will see a successful CAS.
But, what if the value committed to A has a higher timestamp than the one
committed to B and C? Then when the partition heals, repair will treat A's as
the correct value, and the write to B and C will be lost.
> 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
