[jira] [Commented] (CASSANDRA-9966) Option to apply statements within a batch sequentially

["Benedict (JIRA)" <ji...@apache.org>]

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

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

We could always have a special resolution process, since here we know the "temporal" (sequential) ordering unambiguously.

It might be said this is ugly, since it is inconsistent with our normal resolution, but in many ways this is more consistent with the behaviour a user would receive applying the statements sequentially, even within the same millisecond, since the client state we keep server side increments the timestamp (if necessary) during execution. So simulating this behaviour without having to actually increment the timestamp seems to be the better of both worlds.

It doesn't leave me super happy to have another behavioural edge case. We already have more of these than we want, though, since drivers providing their own timestamps will each presumably have their own behaviour here. I think we should perhaps formalise the correct behaviour, make it part of any driver API, and make ourselves as consistent with the formalisation in each location as possible.

> 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)