Note that even if a class is annotated with this annotation, it still needs method-level annotation (such as
CacheStarted) to actually receive notifications.

Objects annotated with this annotation - listeners - can be attached to a running Cache so
users can be notified of Cache events.

There can be multiple methods that are annotated to receive the same event,
and a method may receive multiple events by using a super type.

Delivery Semantics

An event is delivered immediately after the
respective operation, but before the underlying cache call returns. For this
reason it is important to keep listener processing logic short-lived. If a
long running task needs to be performed, it's recommended to use another
thread.

Transactional Semantics

Since the event is delivered during the actual cache call, the transactional
outcome is not yet known. For this reason, events are always delivered, even
if the changes they represent are discarded by their containing transaction.
For applications that must only process events that represent changes in a
completed transaction, TransactionalEvent.getTransaction() can be used,
along with TransactionCompletedEvent.isSuccessful() to record events and
later process them once the transaction has been successfully committed.
Example 4 demonstrates this.

Threading Semantics

A listener implementation must be capable of handling concurrent invocations. Local
notifications reuse the calling thread; remote notifications reuse the network thread.

Since notifications reuse the calling or network thread, it is important to realise that
if your listener implementation blocks or performs a long-running task, the original caller which
triggered the cache event may block until the listener callback completes. It is therefore a good idea to use
the listener to be notified of an event but to perform any
long running tasks in a separate thread so as not to block the original caller.

In addition, any locks acquired for the operation being performed will still be held for the callback. This needs to be kept in mind
as locks may be held longer than necessary or intended to and may cause deadlocking in certain situations. See above paragraph
on long-running tasks that should be run in a separate thread.