Events Properties and Behavior in Cache

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 and the clients determine what action is taken in response to the event.
  • A client can register for multiple events and can also handle multiple events from multiple caches.
  • Events are typically used to signal common cache operations like Add, Insert, Remove and Cache Cleared.

Cache Level Events

NCache provides various levels of events. Events may be raised for cache level activity specific to all items, i.e. any change in the cache data or cache level management operations, such as cleared and stopped. Moreover, events can be specified to the keys which means whenever the specific keys of interest are modified, a notification is raised.

If the client has registered interest in receiving events like addition, insertion, removal of any cache item or when cache is cleared, NCache will notify them about it. Cache Level Events are further divided into following sub-categories:

Item Level Events

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

Management Operation Events

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

Custom Level Events

Note

This feature is only available in NCache Enterprise Edition.

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

Query Events

Note

This feature is only available in NCache Enterprise Edition.

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

Event Filters

NCache also provides events based on a specified filter. This filter specifies the amount of information returned upon event execution. The types of event filters are explained below.

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. By default, this filter is set on specified events.

MetaData

Note

This feature is only available in NCache Enterprise Edition.

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

DataWithMetaData

Note

This feature is only available in NCache Enterprise Edition.

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 absolutely necessary as it is a network expensive trip.

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 topology, 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 the 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 disconnection, the events are not logged during the disconnected time span of the client.

See Also

Cache Level Events
Item Level Event Notifications
Pub/Sub Messaging
Search Cache with LINQ