You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cassandra.apache.org by "Claude Warren, Jr via dev" <de...@cassandra.apache.org> on 2022/08/19 09:04:44 UTC

Is this an MV bug?

# Table definitions

Table [ Primary key ] other data
base  [ A B C ] D E
MV    [ D C ] A B E


# Initial  data
base           -> MV
[ a b c ] d e  -> [d c] a b e
[ a' b c ] d e -> [d c] a' b e


## Mutations -> expected outcome

M1: base [ a b c ] d e'  -> MV [ d c ] a b e'
M2: base [ a b c ] d' e -> MV [ d' c ] a b e

## processing bug
Assume lock can not be obtained during processing of M1.

The mutation M1 sleeps to wait for lock. (Trunk Keyspace.java : 601 )

Assume M2 obtains the lock and executes.

MV is now
[ d' c ] a b e

M1 then obtains the lock and executes

MV is now
[ d c ] a b e'
[ d' c] a b e

base is
[ a b c ] d e'

MV entry "[ d' c ] a b e" is orphaned

Re: Is this an MV bug?

Posted by "Claude Warren, Jr via dev" <de...@cassandra.apache.org>.
Perhaps my diagram was not clear.  I am starting with mutations on the base
table.  I assume they are not bundled together so from separate CQL
statements.

On Fri, Aug 19, 2022 at 11:11 AM Claude Warren, Jr <cl...@aiven.io>
wrote:

> If each mutation comes from a separate CQL they would be separate, no?
>
>
> On Fri, Aug 19, 2022 at 10:17 AM Benedict <be...@apache.org> wrote:
>
>> If M1 and M2 both operate over the same partition key they won’t be
>> separate mutations, they should be combined into a single mutation before
>> submission to SP.mutate
>>
>> > On 19 Aug 2022, at 10:05, Claude Warren, Jr via dev <
>> dev@cassandra.apache.org> wrote:
>> >
>> > 
>> >
>> > # Table definitions
>> >
>> > Table [ Primary key ] other data
>> > base  [ A B C ] D E
>> > MV    [ D C ] A B E
>> >
>> >
>> > # Initial  data
>> > base           -> MV
>> > [ a b c ] d e  -> [d c] a b e
>> > [ a' b c ] d e -> [d c] a' b e
>> >
>> >
>> > ## Mutations -> expected outcome
>> >
>> > M1: base [ a b c ] d e'  -> MV [ d c ] a b e'
>> > M2: base [ a b c ] d' e -> MV [ d' c ] a b e
>> >
>> > ## processing bug
>> > Assume lock can not be obtained during processing of M1.
>> >
>> > The mutation M1 sleeps to wait for lock. (Trunk Keyspace.java : 601 )
>> >
>> > Assume M2 obtains the lock and executes.
>> >
>> > MV is now
>> > [ d' c ] a b e
>> >
>> > M1 then obtains the lock and executes
>> >
>> > MV is now
>> > [ d c ] a b e'
>> > [ d' c] a b e
>> >
>> > base is
>> > [ a b c ] d e'
>> >
>> > MV entry "[ d' c ] a b e" is orphaned
>> >
>> >
>>
>>

Re: Is this an MV bug?

Posted by "Claude Warren, Jr via dev" <de...@cassandra.apache.org>.
If each mutation comes from a separate CQL they would be separate, no?


On Fri, Aug 19, 2022 at 10:17 AM Benedict <be...@apache.org> wrote:

> If M1 and M2 both operate over the same partition key they won’t be
> separate mutations, they should be combined into a single mutation before
> submission to SP.mutate
>
> > On 19 Aug 2022, at 10:05, Claude Warren, Jr via dev <
> dev@cassandra.apache.org> wrote:
> >
> > 
> >
> > # Table definitions
> >
> > Table [ Primary key ] other data
> > base  [ A B C ] D E
> > MV    [ D C ] A B E
> >
> >
> > # Initial  data
> > base           -> MV
> > [ a b c ] d e  -> [d c] a b e
> > [ a' b c ] d e -> [d c] a' b e
> >
> >
> > ## Mutations -> expected outcome
> >
> > M1: base [ a b c ] d e'  -> MV [ d c ] a b e'
> > M2: base [ a b c ] d' e -> MV [ d' c ] a b e
> >
> > ## processing bug
> > Assume lock can not be obtained during processing of M1.
> >
> > The mutation M1 sleeps to wait for lock. (Trunk Keyspace.java : 601 )
> >
> > Assume M2 obtains the lock and executes.
> >
> > MV is now
> > [ d' c ] a b e
> >
> > M1 then obtains the lock and executes
> >
> > MV is now
> > [ d c ] a b e'
> > [ d' c] a b e
> >
> > base is
> > [ a b c ] d e'
> >
> > MV entry "[ d' c ] a b e" is orphaned
> >
> >
>
>

Re: Is this an MV bug?

Posted by Benedict <be...@apache.org>.
If M1 and M2 both operate over the same partition key they won’t be separate mutations, they should be combined into a single mutation before submission to SP.mutate

> On 19 Aug 2022, at 10:05, Claude Warren, Jr via dev <de...@cassandra.apache.org> wrote:
> 
> 
> 
> # Table definitions
> 
> Table [ Primary key ] other data
> base  [ A B C ] D E 
> MV    [ D C ] A B E
> 
> 
> # Initial  data
> base           -> MV 
> [ a b c ] d e  -> [d c] a b e
> [ a' b c ] d e -> [d c] a' b e
> 
> 
> ## Mutations -> expected outcome
> 
> M1: base [ a b c ] d e'  -> MV [ d c ] a b e'
> M2: base [ a b c ] d' e -> MV [ d' c ] a b e
> 
> ## processing bug
> Assume lock can not be obtained during processing of M1.
> 
> The mutation M1 sleeps to wait for lock. (Trunk Keyspace.java : 601 )
> 
> Assume M2 obtains the lock and executes.
> 
> MV is now 
> [ d' c ] a b e
> 
> M1 then obtains the lock and executes
> 
> MV is now 
> [ d c ] a b e'
> [ d' c] a b e
> 
> base is 
> [ a b c ] d e'
> 
> MV entry "[ d' c ] a b e" is orphaned
> 
>