Events Overview

Client applications have to register events for cache activities they are interested in. Whenever some activity of interest takes place in the cache, it publishes events to its subscribed clients. This allows runtime data sharing of single cache shared by separate applications or separate modules of same application.

NCache provides event driven fetching of data, which allows client application to receive events every time data in the cache is updated, added or removed. This allows client applications to receive data without any explicit data fetch request to the cache server.

Properties of Events

Events have the following properties:

The cache determines when an event is raised; the clients determine what action is taken in response to the event.
A client can register for multiple events. It can also handle multiple events from multiple caches.
Events are typically used to signal common cache operations like Add, Insert, Remove, Delete and Cache Cleared.

Event Levels

NCache provides various level of events. Events may be raised for cache level activity specific to all items, i.e. any change in the cache data or may be may be raised for cache level management operations such as cleared and stopped. Moreover, events can be specificied to the keys which means whenever the specific keys of interest are modified or removed, notification is raised. NCache also provides events based on filter specified. The filter specifies the amount of information returned upon event execution. These filters can either be:

None(Default):

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.

Following are the levels of events raised against various types of data sets.

Cache Level Events

NCache can notify clients on addition, insertion, and removal of any cache item or if the cache is cleared, if the client has registered interest in receiving such events. Cache level events are further divided into sub-categories:

Item Based Events:

Events generated on add, update or remove data set from the cache.
Management Operation Events:

Events generated on cache clearing, stopping or member join/leave operation.

Item Level Events

NCache allows the user to select a specific chunk of keys for which the notifications are then triggered. These notifications are then synchronously sent to the client.

Custom Events

Custom level events are special types of notifications which follow a Pub/Sub communication model.

Query Events

NCache also allows you to register event notification for selective data set in the cache. For this, user has to register event through SQL-like criteria.

Topology Wise Behavior

Events notifications are fired according to the cache topology being used. The topology wise behavior for event notifications is described as follows:

Mirror Topology

In mirror, active node of the cluster is responsible to notify the event to client.

Replicated Topology

In replicated topology, the node in cluster which is connected to the client is responsible to raise the event notifications.

Partition of Replica Topology

In partition of replica topology, events are fired from coordinate nodes i.e. active nodes. The node where criteria based data resides, is responsible for event notifications.

Partitioned Topology

In partitioned topology, events are fired from all nodes. The node where criteria based data resides, is responsible for event notifications.

Warning

In case of client disconnectivity, the events are not logged during the disconnected time span of the client.