cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sylvain Lebresne (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-9966) batched CAS statements are not serializable
Date Sun, 16 Aug 2015 15:44:46 GMT

    [ https://issues.apache.org/jira/browse/CASSANDRA-9966?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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)

Mime
View raw message