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.
