[
https://issues.apache.org/jira/browse/CASSANDRA-14323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer resolved CASSANDRA-14323.
----------------------------------------
Resolution: Won't Fix
Reproduced In: 3.11.2, 2.1.13 (was: 2.1.13, 3.11.2)
> 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]
