Package com.tangosol.util

Interface MapListenerSupport.SynchronousListener<K,V>

All Superinterfaces:
EventListener, MapListener<K,V>, SynchronousListener<K,V>
All Known Subinterfaces:
MapListenerSupport.PrimingListener<K,V>
All Known Implementing Classes:
CachingMap.DeactivationListener, CachingMap.FrontMapListener, CachingMap.PrimingListener, CachingMap.SimpleListener, ContinuousQueryCache.AddListener, ContinuousQueryCache.DeactivationListener, ContinuousQueryCache.RemoveListener, InvocableMapHelper.IndexAdapter, LocalCacheSynchronousMapListener, MapListenerProxy.DeactivationListener, MapListenerProxy.WrapperPrimingListener, MapListenerSupport.WrapperPrimingListener, MapListenerSupport.WrapperSynchronousListener, PartitionedCacheConfigurationMapListener, PartitionedCacheSynchronousMapListener
Enclosing class:
MapListenerSupport
public static interface MapListenerSupport.SynchronousListener<K,V> extends SynchronousListener<K,V>, MapListener<K,V>
A tag interface indicating that tagged MapListener implementation has to receive the MapEvent notifications in a synchronous manner.

Consider a MapListener that subscribes to receive notifications for distributed (partitioned) cache. All events notifications are received by the service thread and immediately queued to be processed by the dedicated event dispatcher thread. This makes it impossible to differentiate between the event caused by the updates made by this thread and any other thread (possibly in a different VM). Forcing the events to be processed on the service thread guarantees that by the time "put" or "remove" requests return to the caller all relevant MapEvent notifications raised on the same member as the caller have been processed (due to the "in order delivery" rule enforced by the TCMP).

This interface should be considered as a very advanced feature, so a MapListener implementation that is tagged as a SynchronousListener must exercise extreme caution during event processing since any delay with return or unhandled exception will cause a delay or complete shutdown of the corresponding cache service.

Note: The contract by the event producer in respect to the SynchronousListener is somewhat weaker then the general one. First, the SynchronousListener implementation should make no assumptions about the event source obtained by MapEvent.getMap(). Second, in the event of [automatic] service restart, the listener has to be re-registered manually (for example, in response to the MEMBER_JOINED event). Third, and the most important, no calls against the NamedCache are allowed during the synchronous event processing (the only exception being a call to remove the listener itself).