Re: Continuous queries and duplicates

Hi Piotr, Unfortunately I do not have answer to the question about ordering guarantees during node crashes for the same affinity key. Hopefully some other Ignite experts would be able to help. But in any case I doubt we will be able to have public guarantee on the same affinity key, as opposed to

Re: Continuous queries and duplicates

Hi Vladimir, thank you for your response. I tested the current behaviour and it seems that the order is maintained for notifications within a partition. Unfortunately, I don’t know how it would behave in exceptional situations like losing partitions, rebalancing etc. Do you think it would be possib

Re: Continuous queries and duplicates

Hi, MVCC caches have the same ordering guarantees as non-MVCC caches, i.e. two subsequent updates on a single key will be delivered in proper order. There is no guarantees Order of updates on two subsequent transactions affecting the same partition may be guaranteed with current implementation (t

Re: Continuous queries and duplicates

> > In my case, values are immutable - I never change them, I just add new > entry for newer versions. Does it mean that I won't have any duplicates > between the initial query and listener entries when using continuous > queries on caches supporting MVCC? I'm afraid there still might be a race.

Re: Continuous queries and duplicates

Hi all, sorry for answering so late. I would like to use SqlQuery because I can leverage indexes there. As it was already mentioned earlier, the partition update counter is exposed through CacheQueryEntryEvent. Initially, I thought that the partition update counter is something what's persisted t

Re: Continuous queries and duplicates

Vladimir, Thanks for referring to the MVCC and Continuous Queries discussion, I knew that saw us discussing a solution of the duplication problem. Let me copy and paste it in here for others: 2) *Initial query*. We implemented it so that user can get some initial > data snapshot and then start re

Re: Continuous queries and duplicates

Guys, FYI: Partition counters are already a part of the public API. The following method reveals this information: CacheQueryEntryEvent#getPartitionUpdateCounter()

Re: Continuous queries and duplicates

Denis, Not really. They are used to ensure that ordering of notifications is consistent with ordering of updates, so that when a key K is updated to V1, then V2, then V3, you never observe V1 -> V3 -> V2. It also solves duplicate notification problem in case of node failures, when the same update

Re: Continuous queries and duplicates

[1] http://apache-ignite-developers.2346864.n4.nabble.com/Continuous-queries-and-MVCC-td33972.html On Thu, Dec 13, 2018 at 11:38 PM Vladimir Ozerov wrote: > Denis, > > Not really. They are used to ensure that ordering of notifications is > consistent with ordering of updates, so that when a key

Re: Continuous queries and duplicates

Vladimir, The partition counter is supposed to be used internally to solve the duplication issue. Does it sound like a right approach then? What would be an approach for SQL queries? Not sure the partition counter is applicable. -- Denis On Thu, Dec 13, 2018 at 11:16 AM Vladimir Ozerov wrote:

Re: Continuous queries and duplicates

Partition counter is internal implemenattion detail, which has no sensible meaning to end users. It should not be exposed through public API. On Thu, Dec 13, 2018 at 10:14 PM Denis Magda wrote: > Hello Piotr, > > That's a known problem and I thought a JIRA ticket already exists. However, > faile

Re: Continuous queries and duplicates

Hello Piotr, That's a known problem and I thought a JIRA ticket already exists. However, failed to locate it. The ticket for the improvement should be created as a result of this conversation. Speaking of an initial query type, I would differentiate from ScanQueries and SqlQueries. For the former