On Tue, Apr 28, 2015 at 3:52 PM, Kornev, Andrey <andrey.kor...@misys.com> wrote:
> Hello, > > There are a couple of things wrt Ignite's CQ API and implementation I'd > like to bring the community's attention to. > > First, a CQ instance is a long living resource. Once started it continues > to run until explicitly stopped by closing its cursor. If the query master > node (the one holding the instance of the QueryCursor) crashes and the Auto > Unsubscribe is off, then it doesn't seem there is any way to stop the CQ > save for a complete restart of the grid. Making it possible to obtain the > instance of the CQ from any grid node, might improve things. > Agree, this sounds like API limitation. I will file a ticket. > > Second, the purpose of the initial query and its usage in the current API > is not clear. It makes one wonder what was the original use case the API > was designed to address? > > A couple of things: > > 1) the implementation doesn't provide a consistent point-in-time snapshot > of the cache (no isolation). The cursor may deliver a more recent version > of an entry if it got updated by a concurrent transaction. The same entry > will also be delivered to the listener as an update event. Please correct > me if I'm wrong. > Well, it depends which query you use. If you use SqlQuery or SqlFieldsQuery as initial query for CQ, then you do get point-in-time isolation (Sergi, please correct me if I am wrong here). For ScanQuery you do not get any isolation, as it is a plain iteration through cache with a predicate. > 2) the delivery of the initial query results is in no way synchronized > with the delivery of the events to the listener. > Yes, you are right. > > This makes the API prone to race conditions and its correct usage > impossible. By "correct usage" I mean the ability to capture point in time > state of the cache followed by the correctly ordered change data events > including the ones that occurred while the initial snapshot was being > processed. In database systems it is also known as "materialized view > maintenance". > > It'd be more practical to deliver the initial state to the listener > instance rather than to the cursor executing in a different thread. It'd > also be necessary to punctuate the end of the initial state delivery and > the beginning of the change data events, so that the listener could switch > from building its initial state to applying incremental updates. > > I'm curious if any of the above makes any sense? This makes sense to me. I think our CQ APIs should provide a way to return initial results as listener notifications as well, instead of returning them in a collection. How would you punctuate the end of initial result set and beginning of the event notifications? > > Thanks > Andrey > "Misys" is the trade name of the Misys group of companies. This email and > any attachments have been scanned for known viruses using multiple > scanners. This email message is intended for the named recipient only. It > may be privileged and/or confidential. If you are not the named recipient > of this email please notify us immediately and do not copy it or use it for > any purpose, nor disclose its contents to any other person. This email does > not constitute the commencement of legal relations between you and Misys. > Please refer to the executed contract between you and the relevant member > of the Misys group for the identity of the contracting party with which you > are dealing. >
