[
https://issues.apache.org/jira/browse/CASSANDRA-18988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17859983#comment-17859983
]
Caleb Rackliffe commented on CASSANDRA-18988:
---------------------------------------------
It looks like the discussion has settled on the dev list, and this behavior
will stay the same for the time being. However, there is still a question of
what we might return to the user generally when no explicit SELECT is defined
in the transaction and we have updates that may or not be applied. That and
mixed conditional/non-conditional updates can be handled as part of
CASSANDRA-18107.
> 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: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
