Re: Is this an MV bug?
You mean entirely distinct CQL statements issued by the same client “concurrently”? If they’re submitted to the same coordinator then M2 will have a higher timestamp than M1, so if M2 applies first then M1 will be a no-op and should not generate any view update. If submitted to different coordinators with server-issued timestamps then unless timestamps clash, one of them will win, but it may not be M2. > On 19 Aug 2022, at 11:14, Claude Warren, Jr via dev > wrote: > > 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 > wrote: >> If each mutation comes from a separate CQL they would be separate, no? >> >> >> On Fri, Aug 19, 2022 at 10:17 AM Benedict 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 >>> > 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?
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 wrote: > If each mutation comes from a separate CQL they would be separate, no? > > > On Fri, Aug 19, 2022 at 10:17 AM Benedict 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?
If each mutation comes from a separate CQL they would be separate, no? On Fri, Aug 19, 2022 at 10:17 AM Benedict 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?
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 > 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 > >
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
