Developing a caching strategy by using the cachespec.xml file

When you develop your storefront, you also need to determine how to cache your store pages.


  1. Plan your caching strategy. Consider which pages to cached and whether to cache pages as a whole page or as page fragments. Determine how cached pages are invalidated.
  2. Create a cache policy file that defines the caching strategy by using the cache-entry element. Open cachespec.xml in the WEB-INF for the module you are creating.
  3. Define the required element class. The class element determines how the WebSphere Application Server interprets the remaining cache policy definition.

    The value command refers to classes that use the WebSphere Commerce programming model. The value servlet refers to servlets or JSP files that are deployed in the WebSphere Application Server servlet engine. Only command invalidation is supported.

  4. Define the required element name. Name is the fully qualified class name of the servlet or command.

    Name values for commands must include the package name for example,

    Name values for servlet and JSP files must include the full URI of the JSP file or servlet to be cached for example,

  5. Define the required element property. The property element takes the following form:
    <property name=key>value</property>

    Where key is the name of the property and value is the corresponding value. You can set optional properties on a cacheable object for example, <property name="consume-subfragments">true</property>

  6. Develop cache-ID rules. Develop these IDs in one of two ways:
    • Recommended: Use the component element that is defined in the cache policy of a cache entry.
    • Write custom Java code to build the ID from input variables and system state.

    Specify dependency ID rules. Use dependency ID elements to specify more 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 run.

  7. Invalidate other cache entries as a side effect of this object execution, if relevant. You can define invalidation rules in 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 run.

  8. If you plan to cache catalog pages in your store, add the invalidation policies from the following files into your store:
    • WC_installdir/samples/dynacache/invalidation/catalog/cachespec.xml
    • WC_installdir/samples/dynacache/invalidation/membergroup/cachespec.xml
      Note: For member group invalidation rules, you add more dependency IDs to the cache entries. See the content of this cachespec.xml file for more details.
    • WC_installdir/samples/dynacache/invalidation/store/cachespec.xml