You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Philip Thompson (JIRA)" <ji...@apache.org> on 2015/08/06 21:33:05 UTC
[jira] [Updated] (CASSANDRA-9966) batched CAS statements are not
serializable
[ https://issues.apache.org/jira/browse/CASSANDRA-9966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Philip Thompson updated CASSANDRA-9966:
---------------------------------------
Assignee: Tyler Hobbs
> batched CAS statements are not serializable
> -------------------------------------------
>
> Key: CASSANDRA-9966
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9966
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Reporter: Sam Overton
> Assignee: Tyler Hobbs
> Priority: Critical
>
> It is possible to batch CAS statements such that their outcome is different to the outcome were they executed sequentially outside of a batch.
> eg.
> a | b | c
> a | 1 | 1
> BEGIN BATCH
> UPDATE foo SET b=2 WHERE a='a' iF c=1
> UPDATE foo SET c=2 WHERE a='a' IF b=1
> APPLY BATCH
> results in
> a | b | c
> a | 2 | 2
> If these statements were not batched, the outcome would be
> UPDATE foo SET b=2 WHERE a='a' iF c=1
> a | b | c
> a | 2 | 1
> UPDATE foo SET c=2 WHERE a='a' IF b=1
> applied=false (pre-condition b=1 not met)
> Cassandra already checks for incompatible preconditions within a batch (eg one statement with IF c=1 and another statement with IF c=2). It should also check for mutations to columns in one statement that affect the pre-conditions of another statement, or it should evaluate the statement pre-conditions sequentially after applying the mutations of the previous statement to an in-memory model of the partition.
> For backwards compatibility this would have to be a new "strict" batch mode, eg.
> BEGIN STRICT BATCH
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)