Developing a caching strategy using the cachespec.xml file
When you develop the storefront, you also need to determine how to cache the store pages.
Procedure
- 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.
- Create a cache policy file that defines the caching strategy using the cache-entry element. Open cachespec.xml in the WEB-INF for the module we are creating.
- Define the required element class. The class element determines how the WebSphere Application
Server interprets the remaining cache policy definition.
<class>servlet</class>
The value command refers to classes that use the WebSphere Commerce programming model. The value servlet refers to servlets or JSP files deployed in the WebSphere Application Server servlet engine. Only command invalidation is supported.
- Define the required element name. Name is the fully qualified class name of the servlet or
command.
<name>/ConsumerDirect/ShoppingArea/CatalogSection/CategorySubsection/CachedStoreCatalogDisplay.jsp</name>
Name values for commands must include the package name for example, com.ibm.commerce.dynacache.commands.MemberGroupsCacheCmdImpl.
Name values for servlet and JSP files must include the full URI of the JSP file or servlet to be cached for example, com.ibm.commerce.struts.ECActionServlet.class.
- 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. We can set optional properties on a cacheable object for example, <property name="consume-subfragments">true</property>
- 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. We 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.
- Invalidate other cache entries as a side effect of this object execution, if relevant. We 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.
- If you plan to cache catalog pages in the store, add the invalidation policies from the following files into the 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
Related tasks
Adding sample invalidation policies to the store's cachespec.xml file
Configure cacheable objects
Developing a caching strategy using the cachespec.xml file
Defining the invalidation policies in cachespec.xml
Related information:
