[
https://issues.apache.org/jira/browse/CASSANDRA-9966?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14698731#comment-14698731
]
Sylvain Lebresne commented on CASSANDRA-9966:
-
I don't think this is a bug in the sense that this is working as designed.
Statements within a batch in CQL are not applied sequentially, they are applied
all at once (they all get the same timestamp in particular), and in that sense
it is consistent for CAS one to also work that way (and hence all conditions
are evaluated on the state the batch is applied to as a whole).
Which is not to say we can't consider as a new feature the ability to have
statements of a batch applied sequentially. That said, I can see a few points
worth considering for the addition of such new feature:
* I think we'd have to do 2 things: 1) evaluate the conditions sequentially and
2) generate increasing timestamps for each statement within the batch (so if 2
statement update the same column, the result is consistent with a sequential
application). The latter could work in practice because we guarantee that 2
conficting CAS operation will have at least a 1ms differences in their
timestamp, and since timestamp are in micros, we could have up to 1000
statements within a batch without having a problem, but that still feels a bit
dodgy in principle (and we'll want to make sure this wouldn't be hard to
maintain post-CASSANDRA-6246).
* Do we only allow that new form for batches that goes through Paxos? In
principle, from a user perspective, there would seems to be no reason to have
such limitation, but the part about bumping the timestamp for each statement
within the batch feels even more dodgy in the non-Paxos case.
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)
