ICacheListener Interface |
Note: This API is now obsolete.
Namespace: GemStone.GemFire.Cache
The ICacheListener type exposes the following members.
Name | Description | |
---|---|---|
![]() | AfterCreate |
Handles the event of a new key being added to a region.
|
![]() | AfterDestroy |
Handles the event of an entry being destroyed.
|
![]() | AfterInvalidate |
Handles the event of an entry's value being invalidated.
|
![]() | AfterRegionClear |
Handles the event of a region being cleared.
|
![]() | AfterRegionDestroy |
Handles the event of a region being destroyed.
|
![]() | AfterRegionDisconnected | |
![]() | AfterRegionInvalidate |
Handles the event of a region being invalidated.
|
![]() | AfterRegionLive |
Handles the event of a region going live.
|
![]() | AfterUpdate |
Handles the event of an entry's value being modified in a region.
|
![]() | Close |
Called when the region containing this callback is destroyed, when
the cache is closed.
|
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.