Setting 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, it is recommended that you clear the disk cache by 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.

You can automate storefront cache invalidation for WebSphere Commerce cached content using dynamic cache during the search re-indexing 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.

Before you begin

Ensure that you have completed the WebSphere Commerce search setup and deployment tasks:
- Deploying the search server

Procedure

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>

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 identifer 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 is:
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 identifer 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 runtime 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 re-indexing.
To determine a reasonable amount of delay, consider the following factors:
- The time of the next re-indexing scheduler command is run. For example, 5 minutes.
- The approximate amount of time that the re-indexing 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.
The default value is 0.

CacheInvalidationForStoreHeader

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

The predefined context variables that can be used in this invalidation identifer 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:
```
<_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 setting up cache invalidation for WebSphere Commerce search, you can start the re-indexing process by Preprocessing and building the search index.