Cache Event Listeners

Cache Event Listeners

Introduction

Cache listeners allow implementers to register callback methods that will be executed when a cache event occurs. Cache listeners implement the CacheEventListener interface. The events include:

an Element has been put
an Element has been updated. Updated means that an Element exists in the Cache with the same key as the Element being put.
an Element has been removed
an Element expires, either because timeToLive or timeToIdle have been reached.

Callbacks to these methods are synchronous and unsynchronized. It is the responsibility of the implementer to safely handle the potential performance and thread safety issues depending on what their listener is doing. Listeners are guaranteed to be notified of events in the order in which they occurred. Elements can be put or removed from a Cache without notifying listeners by using the putQuiet and removeQuiet methods. In clustered environments event propagation can be configured to be propagated only locally, only remotely, or both. The default is both, to be backwardly compatible.

Configuration

Cache event listeners are configured per cache. Each cache can have multiple listeners. Each listener is configured by adding a cacheEventListenerFactory element as follows:

               <cache ...>
  <cacheEventListenerFactory class="" properties="" listenFor=""/>
  ...
</cache>

The entry specifies a CacheEventListenerFactory which is used to create a CacheEventListener, which then receives notifications. The attributes of a CacheEventListenerFactory are:

class - a fully qualified factory class name
properties - an optional comma separated properties having meaning only to the factory.
listenFor - describes which events will be delivered in a clustered environment, defaults to ‘all’.

These are the possible values:
- all - the default is to deliver all local and remote events
- local - deliver only events originating in the current node
- remote - deliver only events originating in other nodes

Callbacks to listener methods are synchronous and unsynchronized. It is the responsibility of the implementer to safely handle the potential performance and thread safety issues depending on what their listener is doing.

Implementing a CacheEventListenerFactory and CacheEventListener

A CacheEventListenerFactory is an abstract factory for creating cache event listeners. Implementers should provide their own concrete factory, extending this abstract factory. It can then be configured in ehcache.xml. The following example demonstrates how to create an abstract CacheEventListenerFactory:

               /**
 * An abstract factory for creating listeners. Implementers should provide their own
 * concrete factory extending this factory. It can then be configured in ehcache.xml
 *
 * @author Greg Luck
 * @version $Id: cache_event_listeners.apt 4369 2011-07-15 19:59:14Z ilevy $
 */
public abstract class CacheEventListenerFactory {
  /**
   * Create a <code>CacheEventListener</code>
   *
   * @param properties implementation specific properties. These are configured as comma
   *                   separated name value pairs in ehcache.xml
   * @return a constructed CacheEventListener
   */
  public abstract CacheEventListener createCacheEventListener(Properties properties);
}

      
   

The following example demonstrates how to create a concrete implementation of the CacheEventListener interface:

               /**
 * Allows implementers to register callback methods that will be executed when a cache event
 *  occurs.
 * The events include:
 * <ol>
 * <li>put Element
 * <li>update Element
 * <li>remove Element
 * <li>an Element expires, either because timeToLive or timeToIdle has been reached.
 * </ol>
 * <p/>
 * Callbacks to these methods are synchronous and unsynchronized. It is the responsibility of
 * the implementer to safely handle the potential performance and thread safety issues
 * depending on what their listener is doing.
 * <p/>
 * Events are guaranteed to be notified in the order in which they occurred.
 * <p/>
 * Cache also has putQuiet and removeQuiet methods which do not notify listeners.
 *
 * @author Greg Luck
 * @version $Id: cache_event_listeners.apt 4369 2011-07-15 19:59:14Z ilevy $
 * @see CacheManagerEventListener
 * @since 1.2
 */
public interface CacheEventListener extends Cloneable {

  /**
   * Called immediately after an element has been removed. The remove method will block until
   * this method returns.
   * <p/>
   * Ehcache does not chech for
   * <p/>
   * As the {@link net.sf.ehcache.Element} has been removed, only what was the key of the
   * element is known.
   * <p/>
   *
   * @param cache   the cache emitting the notification
   * @param element just deleted
   */
  void notifyElementRemoved(final Ehcache cache, final Element element) throws CacheException;

  /**
   * Called immediately after an element has been put into the cache. The
   * {@link net.sf.ehcache.Cache#put(net.sf.ehcache.Element)} method
   * will block until this method returns.
   * <p/>
   * Implementers may wish to have access to the Element's fields, including value, so the
   * element is provided. Implementers should be careful not to modify the element. The
   * effect of any modifications is undefined.
   *
   * @param cache   the cache emitting the notification
   * @param element the element which was just put into the cache.
   */
  void notifyElementPut(final Ehcache cache, final Element element) throws CacheException;

  /**
   * Called immediately after an element has been put into the cache and the element already
   * existed in the cache. This is thus an update.
   * <p/>
   * The {@link net.sf.ehcache.Cache#put(net.sf.ehcache.Element)} method
   * will block until this method returns.
   * <p/>
   * Implementers may wish to have access to the Element's fields, including value, so the
   * element is provided. Implementers should be careful not to modify the element. The
   * effect of any modifications is undefined.
   *
   * @param cache   the cache emitting the notification
   * @param element the element which was just put into the cache.
   */
  void notifyElementUpdated(final Ehcache cache, final Element element) throws CacheException;
  
  /**
   * Called immediately after an element is <i>found</i> to be expired. The
   * {@link net.sf.ehcache.Cache#remove(Object)} method will block until this method returns.
   * <p/>
   * As the {@link Element} has been expired, only what was the key of the element is known.
   * <p/>
   * Elements are checked for expiry in Ehcache at the following times:
   * <ul>
   * <li>When a get request is made
   * <li>When an element is spooled to the diskStore in accordance with a MemoryStore
   * eviction policy
   * <li>In the DiskStore when the expiry thread runs, which by default is
   * {@link net.sf.ehcache.Cache#DEFAULT_EXPIRY_THREAD_INTERVAL_SECONDS"/>
   * </ul>
   * If an element is found to be expired, it is deleted and this method is notified.
   *
   * @param cache   the cache emitting the notification
   * @param element the element that has just expired
   *    <p/>
   *    Deadlock Warning: expiry will often come from the <code>DiskStore</code>
   *    expiry thread. It holds a lock to the DiskStore at the time the
   *    notification is sent. If the implementation of this method calls into a
   *    synchronized <code>Cache</code> method and that subsequently calls into
   *    DiskStore a deadlock will result. Accordingly implementers of this method
   *    should not call back into Cache.
   */
  void notifyElementExpired(final Ehcache cache, final Element element);

  /**
   * Give the replicator a chance to cleanup and free resources when no longer needed
   */
  void dispose();

  /**
   * Creates a clone of this listener. This method will only be called by Ehcache before a
   * cache is initialized.
   * <p/>
   * This may not be possible for listeners after they have been initialized. Implementations
   * should throw CloneNotSupportedException if they do not support clone.
   * @return a clone
   * @throws CloneNotSupportedException if the listener could not be cloned.
   */
  public Object clone() throws CloneNotSupportedException;
}

      
   

Two other methods are also available:

void notifyElementEvicted(Ehcache cache, Element element)

Called immediately after an element is evicted from the cache. Eviction, which happens when a cache entry is deleted from a store, should not be confused with removal, which is a result of calling Cache.removeElement(Element).
void notifyRemoveAll(Ehcache cache)

Called during Ehcache.removeAll() to indicate that all elements have been removed from the cache in a bulk operation. The usual notifyElementRemoved(net.sf.ehcache.Ehcache, net.sf.ehcache.Element) is not called. Only one notification is emitted because performance considerations do not allow for serially processing notifications where potentially millions of elements have been bulk deleted.

The implementations need to be placed in the classpath accessible to Ehcache. See the chapter on Classloading for details on how the loading of these classes will be done.

Adding a Listener Programmatically

To add a listener programmatically, follow this example:

               cache.getCacheEventNotificationService().registerListener(myListener);