Ehcache (2.9.x)-Configuration guide, configuring Cache

AboutEhcache Configuration

Ehcache supports declarative configuration via an XML configuration file, as well as programmatic configuration via class- Constructor APIs. Choosing one approach over the other can is a matter of preference or a requirement, such as when an application requires A certain Run-time context to determine appropriate configuration settings.

If your project permits the separation of the configuration from run time use, there is advantages to the declarative APPROAC H:

• The Cache configuration can be changed more easily at deployment time.
• Configuration can is centrally organized for greater visibility.
• Configuration lifecycle can separated from Application-code lifecycle.
• Configuration errors is checked at the startup rather than causing an unexpected runtime error.
• If the configuration file is not provided, a default configuration was always loaded at runtime.

This guide focuses the on XML declarative configuration. Programmatic configuration is explored in certain examples and are documented in the Javadoc.

XML Configuration

by default, Ehcache looks for an ASCII or UTF8 encoded XML configuration file Called ehcache.xml  at the top Level of the Java classpath . you may specify alternate paths and filenames for the XML configuration file by using the VA Rious CacheManager Constructors as described in the Cachemanager javadoc.

To avoid resource conflicts, one XML configuration was required for each CacheManager this is created. For example, directory paths and listener ports require unique values. Ehcache would attempt to resolve conflicts, and, if one is found, it'll emit a warning reminding the user to use Sepa Rate configurations for multiple cachemanagers.

A Sample Ehcache.xml file is included in the Ehcache distribution. It contains full commentary in how to configure each element. This file can also is downloaded from http://ehcache.org/ehcache.xml.

Note: Prior to ehcache-1.6, Ehcache only supported ASCII ehcache.xml configuration files. Starting with ehcache-1.6, UTF8 are supported, so the configuration can use Unicode. Because UTF8 is backwardly compatible with ASCII, no conversion is necessary.

Note: Some elements documented in the Ehcache.xml sample file pertain only to the Terracotta BigMemory products A ND is not valid for the Open-source version of Ehcache.

ehcache.xsd

Ehcache configuration files must comply with the Ehcache XML schema, ehcache.xsd, which can downloaded from HT Tp://ehcache.org/ehcache.xsd.

The Ehcache distribution also contains a copy of ehcache.xsd.

Note: Note that some elements documented by the Ehcache XML schema pertain only to the Terracotta BigMemory produ CTS and is not valid for the Open-source version of Ehcache.

Ehcache-failsafe.xml

If the CacheManager default constructor or Factory method is called, Ehcache looks for a file called ehcache.xml in the top level of the classpath. Failing that, it looks for ehcache-failsafe.xml in the classpath. The ehcache-failsafe.xml file is packaged with the Ehcache JAR and should always be found.

Ehcache-failsafe.xml provides a simple default configuration to enable users to get started before they create th Eir own ehcache.xml.

When ehcache-failsafe.xml is used, Ehcache would emit a warning, reminding the user to set up a proper Configu Ration. The meaning of the elements and attributes is explained in the sections on ehcache.xml.

<Ehcache>   <DiskstorePath= "Java.io.tmpdir"/>   <DefaultcacheMaxentrieslocalheap= "10000"Eternal= "false"Timetoidleseconds= "+"Timetoliveseconds= "+"Maxentrieslocaldisk= "10000000"Diskexpirythreadintervalseconds= "+"Memorystoreevictionpolicy= "LRU">      <PersistenceStrategy= "Localtempswap"/>   </Defaultcache> </Ehcache>

About Default Cache

The Defaultcache configuration is a applied to any of the caches that are not explicitly configured. The defaultcache appears in the ehcache-failsafe.xml file by default, and can also is added to any C5>ehcache configuration file.

While the defaultcache configuration isn't required, an error is generated if caches be created by name (Progra mmatically) with no defaultcache loaded.

Dynamically changing Cache Configuration

While most of the Ehcache configuration was not changeable after startup, since Ehcache 2.0, certain cache Configur ation parameters can is modified dynamically at runtime. These include the following:

• Expiration Settings
  • timeToLive  –the maximum number of seconds an element can exist in the cache regardless of access. The element expires at this limit and would no longer is returned from the cache. the default value is 0, which means no TTL eviction takes place (infinite lifetime).
    
  • Timetoidle  –the maximum number of seconds an element can exist in the cache without Bei ng accessed. The element expires at this limit and would no longer is returned from the cache. the default value is 0, which means no TTI eviction takes place (infinite lifetime).

  Note that the eternal attribute if set to ' true ', overrides timeToLive and timetoidle so tha T expiration can take place.

• Local Sizing Attributes
  • Maxentrieslocalheap
    
  • Maxbyteslocalheap
  • Maxentrieslocaldisk
  • Maxbyteslocaldisk
• Memory-store eviction Policy.
• Cacheeventlisteners can added and removed dynamically

This example shows how to dynamically modify the cache configuration of a running cache:

Cache cache = Manager.getcache ("Samplecache"= cache.getcacheconfiguration (); Config.settimetoidleseconds (); Config.settimetoliveseconds (+); Config.setmaxentrieslocalheap (10000); Config.setmaxentrieslocaldisk (1000000);

Dynamic cache configurations can also is disabled to prevent the future changes:

Cache cache = Manager.getcache ("Samplecache"); Cache.disabledynamicfeatures ();

InchEhcache.xml, you can disable dynamic configuration by setting the <ehcache> element ' s dynamicconfig attribute to "false".

Passing Copies Instead of References

By default, a get () operation in a store returns a reference to the requested data, and any changes to that data is immediately reflected in the memory store. In cases where an application requires a copy of data rather than a reference to it, you can configure the store to return a copy. This allows a copy of the data without affecting the original data in the memory store.

This is configured using the copyonread and copyonwrite attributes of the <cache> and < Defaultcache> elements in your configuration, or programmatically as follows:

New Cacheconfiguration ("Copycache", +)                                    . Copyonread(true). Copyonwrite (true   new Cache (config);

The default configuration is ' false ' for both options.

To copy elements on put ()-like and/or get ()-like operations, a copy strategy is used. The default implementation uses serialization to copy elements. You can provide your own implementation of Net.sf.ehcache.store.compound.CopyStrategy using the <copyStrategy> elem Ent:

<Cachename= "Copycache"Maxentrieslocalheap= "Ten"Eternal= "false"Timetoidleseconds= "5"Timetoliveseconds= "Ten"Copyonread= "true"Copyonwrite= "true">   <Copystrategyclass= "Com.company.ehcache.MyCopyStrategy"/> </Cache>

A Single instance of your copystrategy is used per cache. Therefore, in your implementation of Copystrategy.copy (t), and T must be thread-safe.

A copy strategy can added programmatically in the following to:

Cacheconfiguration cacheconfiguration = new Cacheconfiguration ("Copycache", 10); Copystrategyconfiguration copystrategyconfiguration = new Copystrategyconfiguration (); Copystrategyconfiguration.setclass ("Com.company.ehcache.MyCopyStrategy"); Cacheconfiguration.addcopystrategy (copystrategyconfiguration);

Ehcache (2.9.x)-Configuration guide, configuring Cache