ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kornev, Andrey" <andrey.kor...@misys.com>
Subject Continuous Query
Date Tue, 28 Apr 2015 20:52:47 GMT

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?

"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.

View raw message