Call us: +1-415-738-4000
The architecture of an Ehcache node can include a number of tiers that store data. One of the most important aspects of managing cached data involves managing the life of that data in those tiers.
Use the figure at right with the definitions below to understand the life of data in the tier of Ehcache nodes backed by the Terracotta Server Array, available with BigMemory Max. These definitions apply similarly in standalone Ehcache, but limited to two tiers (heap and disk). BigMemory Go can add an off-heap tier to standalone nodes.
The sections below explore in more detail the aspects of managing data life in Ehcache and the TSA, including the pinning features of Automatic Resource Control (ARC).
Cache entries expire based on parameters with configurable values. When eviction occurs, expired elements are the first to be removed. Having an effective expiration configuration is critical to optimizing use of resources such as heap and maintaining cache performance.
To add expiration, edit the values of the following
<cache> attributes and tune these values based on results of performance tests:
timeToIdleSeconds– The maximum number of seconds an element can exist in the cache without being accessed. The element expires at this limit and will no longer be returned from the cache. The default value is 0, which means no TTI eviction takes place (infinite lifetime).
timeToLiveSeconds– The maximum number of seconds an element can exist in the cache regardless of use. The element expires at this limit and will no longer be returned from the cache. The default value is 0, which means no TTL eviction takes place (infinite lifetime).
maxEntriesLocalDisk– The maximum sum total number of elements (cache entries) allowed on the disk tier for the cache. If this target is exceeded, eviction occurs to bring the count within the allowed target. The default value is 0, which means no eviction takes place (infinite size is allowed). A setting of 0 means that no eviction of the cache's entries takes place, and consequently can cause the node to run out of disk space.
eternal– If the cache’s
eternalflag is set, it overrides any finite TTI/TTL values that have been set.
See How Configuration Affects Element Eviction for more information on how configuration can impact eviction. See this BigMemory Max document on distributed cache configuration for definitions of other available configuration properties.
Data that should remain in the cache regardless of resource constraints can be pinned.
Entire caches can be pinned using the
pinning element in cache configuration. This element has a required attribute (
store) to specify which data tiers the cache should be pinned to:
<pinning store="localMemory" />
store attribute can have one of the following values:
For example, the following cache is configured to pin its entries:
<cache name="Cache1" ... > <pinning store="inCache" /> </cache>
The following cache is configured to pin its entries to heap only:
<cache name="Cache2" ... > <pinning store="localMemory" /> </cache>
Pinning as a setting exists in the local Ehcache client memory. It is never replicated or distributed in a cluster. Pinning achieved programmatically will not be persisted — after a restart the pinned entries are no longer pinned. Cache pinning in configuration is reinstated with the configuration file.
To unpin all of a cache's pinned entries, clear the cache. Specific entries can be removed from a cache using
Cache.remove(). To empty the entire cache, use
Cache.removeAll(). If the cache itself is removed (
CacheManager.removeCache()), then any data still remaining in the cache is also removed locally.
Caches can also be cleared using the Terracotta Management Console.
The following example shows a cache with certain expiration settings:
<cache name="myCache" maxEntriesLocalDisk="10000" eternal="false" timeToIdleSeconds="3600" timeToLiveSeconds="0" memoryStoreEvictionPolicy="LFU"> </cache>
Note the following about the myCache configuration:
timeToIdleSeconds) causes that element to be evicted.
timeToLiveSeconds). However, unexpired entries may still be flushed based on other limitations (see How to Size Caches).
maxEntriesLocalDisk). This is the effective maximum number of entries myCache is allowed. Note, however, that this value may be exceeded as it is overridden by settings such as pinning.
Pinning takes priority over configured cache sizes. For example, in the following cache pinning configuration overrides the
<cache name="myCache" maxEntriesLocalHeap="10000" ... > <pinning store="localHeap" /> </cache>
While expired cache entries (even ones that have been pinned) can always be flushed and eventually evicted from the cluster, most non-expired elements can as well if resource limitations are reached. However, elements resident in a pinned cache cannot be evicted if they haven't expired.
|Potentially, pinned caches could grow to an unlimited size. Caches should never be pinned unless they are designed to hold a limited amount of data (such as reference data) or their usage and expiration characteristics are understood well enough to conclude that they cannot cause errors.|