Skip Headers
Oracle® Coherence Client Guide
Release 3.7.1

Part Number E22839-01
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
View PDF

20 Performing Continuous Queries (.NET)

While it is possible to obtain a point in time query result from a Coherence for .NET cache, and it is possible to receive events that would change the result of that query, Coherence for .NET provides a feature that combines a query result with a continuous stream of related events to maintain an up-to-date query result in a real-time fashion. This capability is called Continuous Query, because it has the same effect as if the desired query had zero latency and the query were being executed several times every millisecond!

Coherence for .NET implements the Continuous Query functionality by materializing the results of the query into a Continuous Query Cache, and then keeping that cache up-to-date in real-time using event listeners on the query. In other words, a Coherence for .NET Continuous Query is a cached query result that never gets out-of-date.

The following sections are included in this chapter:

20.1 Uses for Continuous Query Caching

There are several different general use cases for Continuous Query Caching:

An example use case is a trading system desktop in which a trader's open orders and all related information must always be maintained in an up-to-date manner. By combining the Coherence*Extend functionality with Continuous Query Caching, an application can support literally tens of thousands of concurrent users.

Note:

Continuous Query Caches are useful in almost every type of application, including both client-based and server-based applications, because they provide the ability to very easily and efficiently maintain an up-to-date local copy of a specified sub-set of a much larger and potentially distributed cached data set.

20.2 Understanding Continuous Query Caching

The Coherence for .NET implementation of Continuous Query is found in the Tangosol.Net.Cache.ContinuousQueryCache class. This class, like all Coherence for .NET caches, implements the standard INamedCache interface, which includes the following capabilities:

Since the ContinuousQueryCache class implements the INamedCache interface, which is the same API provided by all Coherence for .NET caches, it is extremely simple to use, and it can be easily substituted for another cache when its functionality is called for.

20.3 Constructing a Continuous Query Cache

There are two items that define a Continuous Query Cache:

The underlying cache is any Coherence for .NET cache, including another Continuous Query Cache. A cache is usually obtained from a CacheFactory, which allows the developer to simply specify the name of the cache and have it automatically configured based on the application's cache configuration information; for example:

INamedCache cache = CacheFactory.GetCache("orders");

The query is the same type of query that would be used to query any other cache; for example:

Filter filter = new AndFilter(new EqualsFilter("getTrader", traderid),
                              new EqualsFilter("getStatus", Status.OPEN));

Normally, to query a cache, a method from the IQueryCache is used; for examples, to obtain a snap-shot of all open trades for this trader:

ICollection setOpenTrades = cache.GetEntries(filter);

Similarly, the Continuous Query Cache is constructed from those same two pieces:

ContinuousQueryCache cacheOpenTrades = new ContinuousQueryCache(cache, filter);

20.4 Cleaning Up Continuous Query Cache Resources

Instances of all INamedCache implementations, including ContinuousQueryCache, should be explicitly released by calling the INamedCache.Release() method when they are no longer needed, to free up any resources they might hold.

If the particular INamedCache is used for the duration of the application, then the resources is cleaned up when the application is shut down or otherwise stops. However, if it is only used for a period, the application should call its Release() method when finished using it.

Alternatively, you can leverage the fact that INamedCache extends IDisposable and that all cache implementations delegate a call to IDisposable.Dispose() to INamedCache.Release(). If you want to obtain and release a cache instance within a single method, you can do so by using a using block:

Example 20-1 Obtaining and Releasing a Reference to a Continuous Query Cache

using (INamedCache cache = CacheFactory.GetCache("my-cache"))
{
   // use cache as usual
}

After the using block terminates, IDisposable.Dispose() is called on the INamedCache instance, and all resources associated with it are released.

20.5 Caching Only Keys Versus Keys and Values

When constructing a Continuous Query Cache, it is possible to specify that the cache should only keep track of the keys that result from the query, and obtain the values from the underlying cache only when they are asked for. This feature may be useful for creating a Continuous Query Cache that represents a very large query result set, or if the values are never or rarely requested. To specify that only the keys should be cached, use the constructor that allows the IsCacheValues property to be configured; for example:

Example 20-2 Caching Only the Keys in a Continuous Query Cache

ContinuousQueryCache cacheOpenTrades = new ContinuousQueryCache(cache, filter, false);

If necessary, the IsCacheValues property can also be modified after the cache has been instantiated; for example:

cacheOpenTrades.IsCacheValues = true;

IsCacheValues Property and Event Listeners

If the Continuous Query Cache has any standard (non-lite) event listeners, or if any of the event listeners are filtered, then the IsCacheValues property is automatically set to true, because the Continuous Query Cache uses the locally cached values to filter events and to supply the old and new values for the events that it raises.

20.6 Listening to a Continuous Query Cache

Since the Continuous Query Cache is itself observable, it is possible for the client to place one or more event listeners onto it. For example:

Example 20-3 Placing a Listener on a Continuous Query Cache

ContinuousQueryCache cacheOpenTrades = new ContinuousQueryCache(cache, filter);
cacheOpenTrades.AddCacheListener(listener);

Assuming some processing has to occur against every item that is in the cache and every item added to the cache, there are two approaches. First, the processing could occur then a listener could be added to handle any later additions:

Example 20-4 Processing Data, then Placing the Listener

ContinuousQueryCache cacheOpenTrades = new ContinuousQueryCache(cache, filter);
foreach (ICacheEntry entry in cacheOpenTrades.Entries)
    {
    // .. process the cache entry
    }
cacheOpenTrades.AddCacheListener(listener);

However, that code is incorrect because it allows events that occur in the split second after the iteration and before the listener is added to be missed! The alternative is to add a listener first, so no events are missed, and then do the processing:

Example 20-5 Placing the Listener, then Processing Data

ContinuousQueryCache cacheOpenTrades = new ContinuousQueryCache(cache, filter);
cacheOpenTrades.AddCacheListener(listener);
foreach (ICacheEntry entry in cacheOpenTrades.Entries)
    {
    // .. process the cache entry
    }

However, the same entry may appear in both an event an in the IEnumerator, and the events can be asynchronous, so the sequence of operations cannot be guaranteed.

The solution is to provide the listener during construction, and it receives one event for each item that is in the Continuous Query Cache, whether it was there to begin with (because it was in the query) or if it was added during or after the construction of the cache:

Example 20-6 Providing the Listener During Continuous Query Cache Construction

ContinuousQueryCache cacheOpenTrades = new ContinuousQueryCache(cache, filter, listener);

20.6.1 Achieving a Stable Materialized View

The Continuous Query Cache implementation faced the same challenge: How to assemble an exact point-in-time snapshot of an underlying cache while receiving a stream of modification events from that same cache. The solution has several parts. First, Coherence for .NET supports an option for synchronous events, which provides a set of ordering guarantees. Secondly, the Continuous Query Cache has a two-phase implementation of its initial population that allows it to first query the underlying cache and then subsequently resolve all of the events that came in during the first phase. Since achieving these guarantees of data visibility without any missing or repeated events is fairly complex, the Continuous Query Cache allows a developer to pass a listener during construction, thus avoiding exposing these same complexities to the application developer.

20.6.2 Support for Synchronous and Asynchronous Listeners

By default, listeners to the Continuous Query Cache have their events delivered asynchronously. However, the Continuous Query Cache does respect the option for synchronous events as provided by the CacheListenerSupport.ISynchronousListener interface.

20.7 Making a Continuous Query Cache Read-Only

The Continuous Query Cache can be made into a read-only cache; for example:

Example 20-7 Making a Continuous Query Cache Read-Only

cacheOpenTrades.IsReadOnly = true;

A read-only Continuous Query Cache does not allow objects to be added to, changed in, removed from or locked in the cache.

When a Continuous Query Cache has been set to read-only, it cannot be changed back to read/write.