Andrey, Your points seem very reasonable to me.
1. Agree that we should have an ability to cancel query from any node at any point. It will help if original node leaves and auto unsubscribe is "false". 2. It is better to use same listener for initial notification. I will think on how to refactor this. 3. As far as distinguishing initial iteration we can add some attribute to entry implementation used in query. We also had several recent requests to enhance continuous query functionality. Give me a couple of days to review code and think everything over and I will file tickets to address CQ issues we have now. Thanks for pointing that out! --Yakov 2015-04-28 23:52 GMT+03:00 Kornev, Andrey <andrey.kor...@misys.com>: > 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. > > 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. > 2) the delivery of the initial query results is in no way synchronized > with the delivery of the events to the listener. > > 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? > > 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. >
