Configure cacheable objects with the cachespec.xml fileDefine cacheable objects inside the cachespec.xml, found inside the Web module WEB-INF or enterprise bean META-INF directory.
You can place a global cachespec.xml in the appserver properties directory, but the recommended method is to place the cache configuration file with the deployment module. The root element of the cachespec.xml file is <cache>, which contains <cache-entry> elements.
Within a <cache-entry>...</cache-entry> element are parameters that allow you to complete the following tasks to enable the dynamic cache with the cachespec.xml file...
- Develop a cachespec.xml file.
- Create a caching configuration file.
In the $WAS_HOME/properties directory, locate the cachespec.sample.xml file.
- Copy the cachespec.sample.xml file to cachespec.xml in Web module WEB-INF or enterprise bean META-INF directory.
- Define the cache-entry elements necessary to identify the cacheable objects. See the topic "Cachespec.xml file" for a list of elements.
- Develop cache-ID rules.
To cache an object, WebSphere Application Server must know how to generate unique IDs for different invocations of that object. The <cache-id> element performs that task. Each cache entry can have multiple cache-ID rules that execute in order until either a rule returns non-empty cache-ID or no more rules remain to execute. If none of the cache-ID generation rules produce a valid cache ID, then the object is not cached. Develop these IDs in one of two ways:
- Use the <component> element defined in the cache policy of a cache entry (recommended)
- Write custom Java code to build the ID from input variables and system state
To configure the cache entry to use the IdGenerator, specify your IdGenerator in the XML file by using the <idgenerator> tag, for example<cache-entry> <class>servlet</class> <name>/servlet/CommandProcessor</name> <cache-id> <idgenerator>com.companyname.SampleIdGeneratorImpl</idgenerator> <timeout>60</timeout> </cache-id> </cache-entry>
- Specifying dependency ID rules.Use dependency ID elements to specify additional cache group identifiers that associate multiple cache entries to the same group identifier.
The dependency ID is generated by concatenating the dependency ID base string with the values returned by its component elements. If a required component returns a null value, then the entire dependency ID does not generate and is not used. You can validate the dependency IDs explicitly through the WebSphere Dynamic Cache API, or use another cache-entry <invalidation> element. Multiple dependency ID rules can exist per cache-entry. All dependency ID rules separately execute. See the topic "Cachespec.xml file" for a list of <component> elements.
- Invalidate other cache entries as a side effect of this object execution, if relevant.You can define invalidation rules in exactly the same manner as dependency IDs. However, the IDs that generate by invalidation rules are used to invalidate cache entries that have those same dependency IDs.
The invalidation ID is generated by concatenating the invalidation ID base string with the values returned by its component element. If a required component returns a null value, then the entire invalidation ID is not generated and no invalidation occurs. Multiple invalidation rules can exist per cache-entry. All invalidation rules separately execute.
- Verify the cacheable page.
Typically you declare several <cache-entry>...</cache-entry> elements inside a cachespec.xml file.
The dynamic cache responds to changes in this file. When new versions of the cachespec.xml are detected, the old policies are replaced. Objects cached through the old policy file are not automatically invalidated from the cache; they are either reused with the new policy or eliminated from the cache through its replacement algorithm.
For each of the three IDs (cache, dependency, invalidation) generated by cache entries, a <cache-entry> can contain multiple elements. The dynamic cache will execute the <cache-id> rules in order, and the first one that successfully generates an ID will be used to cache that output. If the object is to be cached, each one of the <dependency-id> elements will be executed to build a set of dependency IDs for that cache entry. Finally, each of the <invalidation> elements will be executed, building a list of IDs that the dynamic cache will invalidate, whether or not this object is cached.
See AlsoUsing the dynamic cache service to improve performance