Continuous Query Overview

Continuous Query is provided by NCache for runtime monitoring and sharing of data related to an observable data set. This allows applications to be notified of all changes that occur within the queried result set in the cache.

For example, a stock exchange web application has many clients interested in the stock values of the companies they have shares in. Such an application needs to reflect very frequent change in its view as stock values change rapidly for any company. Here, continuous queries come in handy as instead of showing stock values of all companies, you can query the cache for only the specific companies the clients are interested in. Hence, whenever the result set will be modified, the client will be notified about it and the client view will be updated with the latest stock values.

Event Types

Changes in result set of a query can be triggered by the following operations:

Add: Adding an item in cache or updating any existing item can add the item in any query.
Update: Updating any existing cache item but it remains in query result set.
Remove: Removing item from cache or updating any existing cached item such that it causes item removal from query result set. Items can also be removed due to expiration, eviction, dependency change or explicit API removal.

Let's assume the cache has a result set for the query "SELECT Data.Product WHERE Category = 'Beverages'".

"Key1" exists in the cache for following Product class object:

Product product = new Product();
product.ProductID = 1001;
product.ProductName = "Coffee";
product.Category = "Food Items";

This item exists in the cache but not in the result set yet as it does not match the criteria. The object is now updated and Category is changed to "Beverages". This means it fulfills the criteria and it is now added to the result set. This will trigger the ItemAdded event type.

The object is now updated to change the ProductName value "Coffee" to "Iced Coffee". This means the object has been modified such that the criteria is unaffected, hence it remains in the result set and triggers the ItemUpdated event type.

The object is now updated again and the Category value is changed from "Beverages" to "Cold Beverages". This reflects that the query criteria is no longer being fulfilled, so "Key1" is to be removed from the result set but not the cache. This triggers the ItemRemoved event type.

Event Data Filters

EventDataFilter is specified to quantify the amount of information returned upon an event execution. Events that are registered then provide the user with the information based on these data filters.

None

This filter returns only the keys affected by the operation in the event notification. This is used if the application is only interested in knowing which keys were affected, for example, an e-commerce site wants to know which product keys were added, and not the values themselves.

Metadata

With this filter, the affected keys along with their cache item metadata are returned in the event notification. The metadata that is returned includes the groups/subgroups, cache item priority, and expiration value associated with the item. For example, an application wants to know which keys were removed from cache and which groups they belonged to.

DataWithMetadata

This filter returns the keys along with the cached items and their associated metadata. This can be used in cases where a banking application might require knowing which customer information has been modified. Hence, it can register notifications for item update operations with this filter so that the item key and modified item is also returned to the user once the event is fired. Using this filter saves the trip of fetching the items again with the Get API. However, this filter must be used where absolutely necessary as it is a network expensive trip.

Warning

EventDataFilter must be carefully set to avoid unnecessary network bandwidth consumption.

You may have an application that has .NET and Java clients. By enabling the data sharing feature on your clustered cache, you can index the same objects for both clients even with the same query. Notifications will be sent to each client irrespective of Java or .NET for cached items added, updated or removed by both clients in any registered query result set.

Operational Cost

While Continuous Query is very helpful for building real time applications with highly changing operational data, there is some extra processing is required for monitoring and notifying clients which consumes resources. Cache clients are not affected because this process is asynchronous. So for efficiently using this feature, if your applications do not require tracking of any query result set, unregister notifications and also unregister the query from your cache.