Configure cacheable objects with the cachespec.xml file

Define cacheable objects inside the cachespec.xml file, found in the Web module WEB-INF directory or the enterprise bean META-INF directory.

It is recommended that you place the cache configuration file with the deployment module. This allows for better organization of caching schemes and easier redeployment, if required. However, you can place a global cachespec.xml in the application server properties directory.

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 enable the dynamic cache using the cachespec.xml file:

  1. Develop a cachespec.xml file.

    1. Create a caching configuration file.
    2. In the QIBM/ProdData/WebAS5/Base/properties directory, locate the cachespec.sample.xml file.

  2. Copy the cachespec.sample.xml file to cachespec.xml in Web module WEB-INF or enterprise bean META-INF directory.

  3. Define the cache-entry elements necessary to identify the servlet. See Cachespec.xml file Go to Help documentation for a list of elements.

  4. Develop cache-ID rules.

    To cache an object, WAS 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 until a rule returns a 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, which is 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 using the <component> element, specify your ID in the XML file:

    <cache-id>
  <component id="outputForInclude1" type="attribute">
    <required>true</required>
  </component>  
  <timeout>120</timeout>
  <priority>2</priority>
</cache-id>

  5. Specify 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, the entire dependency ID does not generate and is not used. You can validate the dependency IDs explicitly through the WAS Dynamic Cache API, or by using another cache-entry <invalidation> element. Multiple dependency ID rules can exist per cache-entry. All dependency ID rules separately execute.

  6. Invalidate other cache entries as a side effect of this object execution, if relevant.

    Define invalidation rules the same way as dependency IDs. The IDs that generate by invalidation rules are used to invalidate cache entries that have those 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.

  7. 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 at run-time. When new versions of the cachespec.xml file 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) that generate by cache entries, a <cache-entry> can contain multiple elements. The dynamic cache executes the <cache-id> rules in order, and the first rule that successfully generates an ID is used to cache that output. If the object should be cached, each of the <dependency-id> elements are executed to build a set of dependency IDs for that cache entry. Finally, each of the <invalidation> elements are executed, building a list of IDs that the dynamic cache invalidates, regardless of whether this object is cached.