Tagging interface for cache entry listeners.
Sub-interfaces exist for the various cache events allowing a listener to be created which implements only those listeners
it is interested in.
The motivation for this design is to allow efficient implementation of network based listeners.
Listeners should be implemented with care. In particular it is important to consider the impact on performance
and latency.
A listener is a user supplied object instance and therefore can only be registered programmatically.
The listeners are fired:
- in order in which they were registered
- after the entry is mutated in the cache
- the calling thread blocks until the listener returns if the listener was registered as synchronous
- asynchronous listeners iterating through multiple events have undefined ordering
A synchronous listener is not permitted to mutate the cache it is listening on.
A listener on a transactional cache is executed orthogonally to the transaction. If synchronous it is executed after the mutation
and not after the transaction commits, and if asynchronous the timing is undefined. A listener which throws an exception will not affect
the transaction. A transaction which is rolled back will not unfire a listener.