Deprecation

This document is DEPRECATED.

Please consider any information here as out of date. DO NOT use this document.

Instead, refer to http://infinispan.org/documentation.

Please update your bookmarks accordingly.

Skip to end of metadata
Go to start of metadata

Introduction

  1. Expiration is a top-level construct, represented in the configuration as well as in the cache API.  More on this later.
  2. While eviction is local to each cache instance , expiration is cluster-wide .  Expiration lifespans and maxIdle values are replicated along with the cache entry.
  3. Expiration lifespan and maxIdle are also persisted in CacheStores, so this information survives eviction/passivation.
  4. Four eviction strategies are shipped, EvictionStrategy.NONE, EvictionStrategy.LRU, EvictionStrategy.UNORDERED, and EvictionStrategy.LIRS.

Configuration

Eviction may be configured using the Configuration bean or the XML file.  Eviction configuration is on a per-cache basis.  Valid eviction-related configuration elements are:

XML changes in Infinispan 5.0
From Infinispan 5.0 onwards, wakeupInterval attribute has been moved to expiration XML element. This is because since 4.1, eviction happens in the user thread, and so the old eviction thread now simply purges expired entries from memory and any attached cache store. So, effectively, wakeUpInterval controls how often this purging occurs:

Programmatically, the same would be defined using:

Default values

Eviction is disabled by default.  If enabled (using an empty <eviction /> element), certain default values are used:

  • strategy: EvictionStrategy.NONE is assumed, if a strategy is not specified..
  • wakeupInterval: 5000 is used if not specified.
    • If you wish to disable the eviction thread, set wakeupInterval to -1.
  • maxEntries: -1 is used if not specified, which means unlimited entries.
    • 0 means no entries, and the eviction thread will strive to keep the cache empty.

Expiration lifespan and maxIdle both default to -1.

Using expiration

Expiration allows you to set either a lifespan or a maximum idle time on each key/value pair stored in the cache.  This can either be set cache-wide using the configuration, as described above, or it can be defined per-key/value pair using the Cache interface.  Any values defined per key/value pair overrides the cache-wide default for the specific entry in question.

For example, assume the following configuration:

Eviction designs

Central to eviction is an EvictionManager - which is only available if eviction or expiration is configured.

The purpose of the EvictionManager is to drive the eviction/expiration thread which periodically purges items from the DataContainer.  If the eviction thread is disabled (wakeupInterval set to -1) eviction can be kicked off manually using EvictionManager.processEviction(), for example from another maintenance thread that may run periodically in your application.

The eviction manager processes evictions in the following manner:

  1. Causes the data container to purge expired entries
  2. Causes cache stores (if any) to purge expired entries
  3. Prunes the data container to a specific size, determined by maxElements
Labels:
expiration expiration Delete
grid grid Delete
infinispan infinispan Delete
eviction eviction Delete
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.
  1. Mar 07, 2012

    Is there way to programmatically create caches in Infinispan without modifying standalone.xml? (I am using Jboss 7.0.2 Final)

  2. Jun 27, 2013

    I wish we could just configure the FQCN/method of a POJO to create/call on wakeupInterval that would just return a boolean on whether to evict/expire. The POJO could do whatever we wanted like monitor a file, do a db call, make an LDAP lookup, etc.