cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Benedict (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-9966) Option to apply statements within a batch sequentially
Date Wed, 16 Sep 2015 10:16:46 GMT

    [ https://issues.apache.org/jira/browse/CASSANDRA-9966?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14747267#comment-14747267
] 

Benedict commented on CASSANDRA-9966:
-------------------------------------

I mean when applying a batch we use special resolution rules of always taking the new value.

If we want to avoid surprising users we probably would need to implement a special resolution
of only incrementing the timestamp on a conflicting resolution, as otherwise users with more
than 1000 batch statements would see a behavioural change that may (possibly) break things?
And when applying individual statements we do effectively resolve this way (just with timestamp
increments). So in order to minimise surprise, it seems simulating timestamp increments, without
actually incrementing them (since we have the necessary information to do so) seems perhaps
the least surprising option.

> Option to apply statements within a batch sequentially
> ------------------------------------------------------
>
>                 Key: CASSANDRA-9966
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-9966
>             Project: Cassandra
>          Issue Type: New Feature
>          Components: Core
>            Reporter: Sam Overton
>             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