[
https://issues.apache.org/jira/browse/CASSANDRA-18988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Rackliffe updated CASSANDRA-18988:
----------------------------------------
Resolution: Not A Problem
Status: Resolved (was: Open)
> Updating the column of a non-existent row in an Accord transaction results in
> Atomicity violation
> -------------------------------------------------------------------------------------------------
>
> Key: CASSANDRA-18988
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18988
> Project: Cassandra
> Issue Type: Bug
> Components: Accord
> Reporter: Luis E Fernandez
> Assignee: Caleb Rackliffe
> Priority: Normal
> Fix For: 5.x
>
>
> *System configuration and information:*
> Single node Cassandra with Accord transactions enabled running on docker
> Built from commit:
> [a7cd114435704b988c81f47ef53d0bfd6441f38b|https://github.com/apache/cassandra/commit/a7cd114435704b988c81f47ef53d0bfd6441f38b]
> CQLSH: [cqlsh 6.2.0 | Cassandra 5.0-alpha2-SNAPSHOT | CQL spec 3.4.7 | Native
> protocol v5]
>
> *Steps to reproduce in CQLSH:*
> {code:java}
> CREATE KEYSPACE accord WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'} AND durable_writes = true;{code}
> {code:java}
> CREATE TABLE accord.accounts (
> partition text,
> account_id int,
> balance int,
> PRIMARY KEY (partition, account_id)
> ) WITH CLUSTERING ORDER BY (account_id ASC);
> {code}
> {code:java}
> BEGIN TRANSACTION
> INSERT INTO accord.accounts (partition, account_id, balance) VALUES
> ('default', 0, 100);
> INSERT INTO accord.accounts (partition, account_id, balance) VALUES
> ('default', 1, 100);
> COMMIT TRANSACTION;{code}
> atomicity bug happens after executing the following statement:
> Based on [Cassandra
> documentation|https://cassandra.apache.org/doc/4.1/cassandra/cql/dml.html#update-statement]
> regarding the use of UPDATE statements, I expect the result of this
> transaction to be the insertion of a new account (\{ account_id: 3, balance:
> 10 }). The total balance across the three (3) accounts should be maintained
> (200). After executing the below transaction, the total number of accounts
> remains at two (2) and the total balance drops to 190. Basically, it appears
> as if only one half of the transaction proceeds.
> {code:java}
> BEGIN TRANSACTION
> UPDATE accord.accounts
> SET balance -= 10
> WHERE
> partition = 'default'
> AND account_id = 1;
> UPDATE accord.accounts
> SET balance += 10
> WHERE
> partition = 'default'
> AND account_id = 3;
> COMMIT TRANSACTION;{code}
> Bug / Error:
> ======================================================================
> The result of performing a table read after executing the buggy transaction
> is:
> {code:java}
> partition | account_id | balance
> -----------+------------+---------
> default | 0 | 100
> default | 1 | 90
> {code}
> {color:#172b4d}Note that the above transactions are not possible without a
> transaction block because only counter type columns can be updated with += or
> -= syntax in normal (non-transactional) cql statements. Using counter type
> columns also results in a separate, related bug:
> [CASSANDRA-18987|https://issues.apache.org/jira/browse/CASSANDRA-18987]{color}
> {color:#172b4d}This was found while testing Accord transactions with
> [~henrik.ingo] and team.{color}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
