[
https://issues.apache.org/jira/browse/CASSANDRA-9966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis updated CASSANDRA-9966:
--------------------------------------
Fix Version/s: 2.2.x
> 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: Sylvain Lebresne
> Priority: Critical
> Fix For: 3.x, 2.2.x
>
>
> 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)
