Consider an ICacheListener 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. 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 cache event notification 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 an ICacheListener implementation that is tagged as an ISynchronousListener 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 ISynchronousListener is somewhat weaker then the general one. First, the ISynchronousListener implementaion should make no assumptions about the event source obtained by Cache.

Second, in the event of [automatic] service restart, the listener has to be re-registered manually.

Third, and the most important, no calls against the INamedCache are allowed during the synchronous event processing (the only exception being a call to remove the listener itself).