[
https://issues.apache.org/jira/browse/CASSANDRA-11023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylvain Lebresne resolved CASSANDRA-11023.
------------------------------------------
Resolution: Invalid
Except that this is not how Paxos work. The non-serial consistency for LWT only
matter for client visibility, not for paxos internally. More precisely a given
round of Paxos will always [wait for a quorum of participants to have seen the
previous commit before processing a new
one|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/service/StorageProxy.java#L435-L449].
> Restrict mutation consistency level to QUORUM+ for LWT
> ------------------------------------------------------
>
> Key: CASSANDRA-11023
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11023
> Project: Cassandra
> Issue Type: Improvement
> Components: Coordination
> Reporter: DOAN DuyHai
>
> 5 nodes cluster, RF = 3
> → LWT consistency = SERIAL
> → Mutation consistency = ONE
> 1. Client 1 sends a INSERT INTO test (partition_key, value) VALUES(*1*,
> *‘ONE’*) IF NOT EXISTS
> 2. Paxos round successfully gets ballot1
> 3. The IF NOT EXISTS condition is validated (reading with QUORUM on all
> replicas)
> 4. Paxos round validated
> 5. Mutation applied using consistency level ONE. Mutation pushed to replicas
> A, B and C
> 6. Replica A sends back acks. *Replicas B and C did not receive the mutation*
> (temporary network issue). The LWT operation is successful since we do not
> wait for acks from B and C
> This LWT is considered successful
> 7. Client 2 starts a LWT : INSERT INTO test (partition_key, value)
> VALUES(*1*, *‘TWO’*) IF NOT EXISTS
> 8. Paxos round successfully gets ballot2 (ballot2 > ballot1)
> 9. The IF NOT EXISTS condition is validated (*reading with QUORUM and replica
> B and C reply that partition 1 does not exist*)
> 10. The semantics of LWT is violated because indeed the partition already
> exists (because first LWT succeeded) with value = ‘ONE’
> I'm not saying that there is a bug in our LWT implementation, it works as
> designed. The problem here is that I can't see any legit/sensible use-case
> for LWT with mutation CL=ONE since it opens the door for edge cases like the
> one described above and it defeats the purpose of Compare And Swap.
> Furthermore it can confuse a lot of people not familiar of how LWT is
> implemented internally.
> Ideally, we should remove/ignore mutation CL for LWT and always use
> QUORUM/LOCAL_QUORUM. But for the sake of not breaking the existing API, it
> would be sufficient enough to validate and reject mutation CL < QUORUM.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
