ICacheListener InterfacePivotal GemFire .NET Client Documentation
An application plug-in that can be installed on a region.

Namespace: GemStone.GemFire.Cache
Assembly: GemStone.GemFire.Cache (in GemStone.GemFire.Cache.dll) Version:

[ObsoleteAttribute("Use classes and APIs from the GemStone.GemFire.Cache.Generic namespace")]
public interface ICacheListener

Listeners are change notifications that are invoked AFTER the change has occured for region update operations on a client. Listeners also receive notifications when entries in a region are modified. Multiple events can cause concurrent invocation of ICacheListener methods. If event A occurs before event B, there is no guarantee that their corresponding ICacheListener method invocations will occur in the same order. Any exceptions thrown by the listener are caught by GemFire and logged. If the exception is due to listener invocation on the same thread where a region operation has been performed, then a CacheListenerException is thrown back to the application. If the exception is for a notification received from server then that is logged and the notification thread moves on to receiving other notifications.

A cache listener is defined in the RegionAttributes.

There are two cases in which listeners are invoked. The first is when a region modification operation (e.g. put, create, destroy, invalidate) is performed. For this case it is important to ensure that minimal work is done in the listener before returning control back to Gemfire since the operation will block till the listener has not completed. For example, a listener implementation may choose to hand off the event to a thread pool that then processes the event on its thread rather than the listener thread. The second is when notifications are received from java server as a result of region register interest calls (Region.RegisterKeys etc), or invalidate notifications when notify-by-subscription is false on the server. In this case the methods of ICacheListener are invoked asynchronously (i.e. does not block the thread that receives notification messages). Additionally for the latter case of notifications from server, listener is always invoked whether or not local operation is successful e.g. if a destroy notification is received and key does not exist in the region, the listener will still be invoked. This is different from the first case where listeners are invoked only when the region update operation succeeds.
See Also