Create store pages that can be cached using cachespec.xml

While developing your storefront you also need to determine how to cache your store pages. This topic discusses creating and implementing a caching strategy for your store.

  1. Plan your caching strategy. You need to consider what pages should be cached and whether they should be cached as a whole page or as page fragments. Your caching strategy should also include how cached pages will be invalidated.

  2. 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 you are creating.

  3. Define the required element class. The class element determines how the WAS will interpret the remaining cache policy definition. 
    <class>servlet</class>

    The value command refers to classes using 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.

  4. 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

    • /AdvancedB2BDirect/ShoppingArea/CatalogSection/CategorySubsection/CachedStoreCatalogDisplay.jsp

  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 being defined 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:

    • 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

    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, 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.

  7. 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.

  8. If you plan to cache catalog pages in your store, you should 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

      For these member group invalidation rules add additional 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

http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/topic/com.ibm.websphere.zseries.doc/info/zseries/ae/rdyn_configxmp.html
Add sample invalidation policies to your store's cachespec.xml file
Configure cacheable objects
Create store pages that can be cached using cachespec.xml
Define the invalidation policies in cachespec.xml

Related reference

Caching defaults