Set up cache invalidation for WebSphere Commerce Search

WebSphere Commerce uses the WebSphere Application Server dynamic cache service for caching servlets or JSP files and commands that extend from the WebSphere Application Server CacheableCommand interface. The dynamic cache service, servlet caching, and disk offload are enabled by default, during the creation of a WebSphere Commerce instance. The dynamic cache service includes the following features:

• Servlet and JSP result cache: To cache whole pages or fragments that are generated by a servlet or a JSP page.

• Command cache: To cache command objects.

• Edge Side Include (ESI) caching: To cache, assemble, and deliver dynamic web pages at the edge of an enterprise network.

• Invalidation Support: To ensure that the content of the cache is correct. Invalidation can be rule-based, time-based, group-based, and programmatic.

• Replication support: To enable cache sharing and replication among multiple servers.

• Disk offload capability: To enable caching large amounts of data, and to preserve cache content while the application server is stopped and restarted.

  Note: After the application server is restarted and the database is restored, IBM recommends that you clear the disk cache using the cache monitor. Clear the disk cache to ensure that information that is invalid for the new database is removed. Use the cache monitor to clear the cache or, alternatively, use the following URL: http://host_name/path/DynaCacheInvalidation?clear=true. For more information, see DynaCacheInvalidation URL.

We can automate storefront cache invalidation for WebSphere Commerce cached content by using dynamic cache during the search reindexing process.

The caching behavior of the WebSphere Application Server dynamic cache service is specified by cache policies that are defined by <cache-entry> elements in cache specification configuration XML (cachespec.xml) files.

Procedure

1. Define a cache policy in cachespec.xml for a JSP file with the proper dependency identifier for emergency search index (delta) updates. For example:

   • To invalidate the ProductDisplay page given a catalog entry identifier:

     <dependency-id>ProductDisplay:productId:langId
     <component id="" ignore-value="true" type="pathinfo">
     <required>true</required>
     <value>/ProductDisplay</value>
     </component>
     <component id="productId" type="parameter">
     <required>true</required>
     </component>
     <component id="DC_lang" type="attribute">
     <required>true</required>
     </component>
     </dependency-id>

   • To invalidate the CategoryDisplay page given a catalog group identifier:

     <dependency-id>CategoryDisplay:categoryId:langId
     <component id="" ignore-value="true" type="pathinfo">
     <required>true</required>
     <value>/CategoryDisplay</value>
     <value>/SearchDisplay</value>
     </component>
     <component id="categoryId" type="parameter">
     <required>true</required>
     	</component>
     <component id="DC_lang" type="attribute">
     	<required>true</required>
     </component>
     </dependency-id>

   • To invalidate the TopCategoriesDisplay page:

     <dependency-id>TopCategoriesDisplay:langId
     <component id="" ignore-value="true" type="pathinfo">
     <required>true</required>
     <value>/TopCategoriesDisplay</value>
     </component>
     <component id="DC_lang" type="attribute">
     <required>true</required>
     </component>
     </dependency-id>

2. Define a corresponding invalidation identifier to be generated by providing a template for the following two properties in the wc-component.xml file:

   CacheInvalidationForCatalogEntry

   There are two invalidation templates provided with this property. The first template is to invalidate the ProductDisplay page. The second template is used for invalidating its immediate parent categories across all catalogs. The predefined context variables that can be used in this invalidation identifier template include:

   catEntryId

   Internal identifier for the modified catalog entry.

   catGroupId

   Internal identifier for its immediate parent category across all catalogs.

   langId

   Internal language identifier for the modifier entry.

   storeId

   Internal store identifier for the modifier entry.

   catalogId

   Internal catalog identifier for the modifier entry.

   The condition for full invalidation:

   if (cacheInvalidationForCatalogEntry != null
   && cacheInvalidationForCatalogEntry.length() > 0) {
   try {
   if (ibFullBuild) {
   // Full cache invalidation
   if (cacheInvalidationForAll != null
   && cacheInvalidationForAll.length() > 0) { 

   CacheInvalidationForCatalogGroup

   There are two invalidation templates provided with this property. The first template is to invalidate the CategoryDisplay page for the current category and all its immediate parent categories across all catalogs. The second template is used for invalidating TopCategoriesDisplay, used in the Home page where affected categories might be present.

   The predefined context variables that can be used in this invalidation identifier template include:

   catGroupId

   Internal identifier for the modified catalog group, and its immediate parent category across all catalogs.

   langId

   Internal language identifier for the modifier entry.

   storeId

   Internal store identifier for the modifier entry.

   catalogId

   Internal catalog identifier for the modifier entry.

   CacheInvalidationForAll

   A cache invalidation operator for full cache invalidation. When the search run time determines that a full cache invalidation is necessary and CacheInvalidationForAll is set (the default value is set to clearall), this value is set into CACHEIVL.DATA_ID to request all cache to be cleared.If this value is not set or left as an empty string ("", no full cache invalidation is performed.

   Note: To allow full cache invalidation to be performed through the DynaCacheInvalidationCmd scheduler command, ensure that enableRefreshRegistry=false is passed in as the one of the job parameters.

   CacheInvalidationDelay

   The delay, in milliseconds, before cache invalidation occurs after each search reindexing.

   To determine a reasonable amount of delay, consider the following factors:

   • The time of the next reindexing scheduler command is run. For example, 5 minutes.

   • The approximate amount of time that the reindexing might take to complete. For example, 2 minutes.

   • The next replication time between the production search index and the Repeater. For example, 1 minute.

   • The approximate amount of time that the index replication might take to complete. For example, 3 minutes.

   In this example, the estimated invalidation delay is the total of 5, 2, 1, and 3 minutes. This equals 11 minutes, or 660000 milliseconds.

   Default is 0.

   CacheInvalidationForStoreHeader

   The StoreHeader invalidation template is used to automate the cache invalidation for storefront cached content by using DynaCache as part of the search reindexing procedure.

   The predefined context variables that can be used in this invalidation identifier template include:

   storeId

   Internal store identifier for the modifier entry.

   catalogId

   Internal catalog identifier for the modifier entry.

   langId

   Internal language identifier for the modifier entry.

   For example:Change the following default fragment:

   <_config:property name="CacheInvalidationForCatalogEntry" value="" />
   <_config:property name="CacheInvalidationForCatalogGroup" value="" />

   To the following fragment:

   <_config:property name="CacheInvalidationForCatalogEntry" value="ProductDisplay:productId:langId:$catEntryId$:$langId$" />
   <_config:property name="CacheInvalidationForCatalogGroup" value="CategoryDisplay:categoryId:langId:$catGroupId$:$langId$" /> 

What to do next

For more information about dynamic cache, see Dynamic caching.

After you set up cache invalidation for WebSphere Commerce Search, we can start the reindexing process by Building the search index.