Continuous Query Overview

NCache provides Continuous Query for the runtime monitoring and data sharing related to observable data sets. 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 the 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 the companies, you can query the cache for only the specific companies the clients are interested in. Hence, whenever the result set is modified, the client will be notified about it and the client view will be updated with the latest stock values.

Event Types

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

• Add: Adding an item in the cache or updating any existing item can add the item in any query.

• Update: Updating any existing cache item but it remains in the query result set.

• Remove: Removing an item from the cache or updating any existing cached item such that it causes item removal from the 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 * FROM FQN.Product WHERE Category = 'Beverages'".

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

var product = new Product
{
    ProductID = 1001,
    ProductName = "Coffee",
    UnitsAvailable = 55,
    Category = "Food Items"
};

• This item exists in the cache but not in the result set yet, as it does not match the criteria. Therefore, 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, cache item priority, and expiration value associated with the item. For example, an application wants to know which keys were removed from the 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 are 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 necessary as it is a network-expensive trip.

Warning

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

Data Sharing For Portable Data Structures

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 .NET or Java 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 required for monitoring and notifying clients which consumes resources. Cache clients are not affected because this process is asynchronous. So, to efficiently use this feature, if your applications do not require tracking of any query result set, unregister notifications and also unregister the query from your cache.

See Also

Using Continuous Query
SQL Reference for NCache
Event Notifications in Cache
Pub/Sub Messaging