For 1), can we have any issues of state on different nodes i.e. communicating effectively to all nodes that a query is canceled with immediate effect?
On Wed, Apr 29, 2015 at 1:53 PM, Yakov Zhdanov <[email protected]> wrote: > 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 <[email protected]>: > > > 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. > > > -- Regards, Atri *l'apprenant*
