Caching and invalidation in WebSphere Commerce Search

The JSP fragment cache and the data object cache can be used with the search server for caching and invalidation. The JSP fragment cache is used on the WebSphere Commerce server to cache portions of the storefront user interface for future reuse. The data object cache is used on the search server to store internal runtime properties that are used by certain search features to improve overall performance.

To prevent over-caching and excessive cached content, search operations are typically not cached. The general recommendations are to not cache full page responses when a keyword is specified in the original request. This approach is also used to handle faceted navigation in the storefront.

Since personalized content or volatile data, such as price or inventory level, can appear on certain cached pages, you can opt out a page fragment from being cached. To achieve this result, use fragment caching. For more information, see WebSphere Commerce Search caching.

After a cache policy is defined in the cachespec.xml file for a JSP page, the DynaCache invalidation for storefront cached content properties are used in the catalog component configuration file (wc-component.xml). For more information, see Search properties in the component configuration file (wc-component.xml) (WebSphere Commerce EAR).

Cache invalidation

Since there is a slight delay between the search index being fully synchronized with the latest database changes, considerations must be taken when you invalidate cached content for search-based catalog navigation. These delays can either be as a result of staging propagation or Quick Publish when you apply an emergency fix.

Storefront cache invalidation is automatically performed when you use Staging Propagation and Quick Publish for emergency fixes. When index replication is complete, a cache invalidation instruction is issued by inserting an entry of type restart into the CACHEIVL table. The entry uses the provided start time parameter as the time to start performing cache invalidation. The DynaCacheInvalidation scheduler command perform the same invalidation, starting at the start time parameter. This schedule prevents early invalidation, which would result in recaching out-of-date content before the latest index changes become available. The invalidation entries in the CACHEIVL table could be dependency IDs used for JSP fragment cache invalidation or data object cache invalidation.

These considerations are based on the following scenarios:Where an index repeater is used to capture the most recent deployed index content and serves as a backup for production targets.

The repeater takes time to replicate the index changes to all of its subordinate servers. All search-based catalog navigation is retrieved by the subordinate servers in the production environment, not the repeater. Therefore, if the cache invalidation occurs immediately after the database changes are completed, and while the search index replication is still occurring, the new cache content might still not be accurate. The search index still contains the old data. Immediately recreating the new cache might result in reusing the old data.

The following items must be considered to determine an appropriate delay, in milliseconds, before the cache invalidation occurs after each search reindexing:
  • The time the next reindexing scheduler command is started
  • The approximate amount of time that the reindexing might take to complete
  • The next replication time between the production search index and the repeater
  • The approximate amount of time that the index replication might take to complete
Where the sum of the time estimates is equal to the approximate required delay time before cache invalidation can occur.