[
https://issues.apache.org/jira/browse/CASSANDRA-14323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16405968#comment-16405968
]
Benjamin Lerer commented on CASSANDRA-14323:
--------------------------------------------
If you look only at you example it is true that the result is surprising.
Now, if you perform the 2 following queries one after the other what result do
you expect?
# {{insert into test.consistency (pk,nk1,nk2) VALUES (2,'nk1','nk2') USING
TIMESTAMP 1521080773000;}}
# {{insert into test.consistency (pk,nk1,nk2) VALUES (2,'nk2','nk1') USING
TIMESTAMP 1521080773000;}}
One or the other? The problem here is that due to the distributed nature of C*
a node can receive the inserts in any order and 2 node of the same cluster can
receive them in different order. Due to that C* cannot rely on the order to
determine which value it should keep, and need to rely on predictable way to
merge those 2 inserts into one row. Unfortunately, there are no perfect way to
do that so an arbitrary rule had to be chosen.
Batches behave in the same way. Which make them {{consistent}} with normal
inserts and other operations. Changing the behavior for batches will make them
inconsistent with the rest of the application.
Multiple collection updates within the same queries follow also the same rules.
I hope it clarifies the things.
> Same timestamp insert conflict resolution breaks row-level data consistency
> ---------------------------------------------------------------------------
>
> Key: CASSANDRA-14323
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14323
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Reporter: Rishi Kathera
> Priority: Minor
>
> When inserting multiple rows with the same primary key and timestamp,
> memtable update logic does not maintain row-level consistency for the key
> inserted. For example,
> {code:java}
> create table test.consistency(pk int PRIMARY KEY , nk1 text, nk2 text);
> BEGIN UNLOGGED BATCH USING TIMESTAMP 1521080773000
> insert into test.consistency (pk,nk1,nk2) VALUES (2,'nk1','nk2');
> insert into test.consistency (pk,nk1,nk2) VALUES (2,'nk2','nk1');
> APPLY BATCH;
> select * from test.consistency;
> {code}
> In this case, I would expect either one row overwrites the other so the
> result of the read would be either
> {code:java}
> 2, nk1, nk2{code}
> or
> {code:java}
> 2, nk2, nk1{code}
> but the row retrieved is
> {code:java}
> 2, nk2, nk2{code}
> which breaks consistency of the writes. This behavior comes from this logic,
> [https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/db/Conflicts.java#L45]
> where it appears that the value of the cell itself is used to resolve
> overwrite conflict which I don't think is the correct way of handling the
> situation. Shouldn't it either be overwrite or not overwrite for all cases?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
