This blog promotes knowledge sharing through experience and collaboration. For more product information, visit our WebSphere Commerce CSE page. For easier navigation, utilize the Categories to find posts that match your interest.
The Data Cache Moves to the Search Server
Since V6, Data Cache has been one of the most important features for performance. To support the new Feature Pack 7 REST capabilities in the Search server, Data Cache has now also been made available in the Search JVMs. In this post I discuss the different configuration options and how invalidations work compared to the Commerce servers.
Finding the Data Cache in the Search server
In the Commerce servers, the Data Cache is optional and can be enabled by either defining the distributed maps in the WebSphere Administrative Console, or with the cacheinstances.properties file (the latter being the most common approach). In the Search servers, the Data Cache distributed maps are defined automatically in the WebSphere configuration during feature enablement and can be found in the Administrative Console under: Resources -> Cache Instances -> Object cache instances.
To see how the caches are getting used, same as with the Commerce server, install the Cache Monitor and apply the Cache Monitor extensions required for distributed maps.
If after reviewing the caching statistics you find that some caches need to be resized, this can be done in the WebSphere Administrative Console. Use the steps above to open the distributed map and update "Cache size".
With no Commerce Scheduler in the Search servers, invalidations are implemented differently. Instead of using the DynacacheInvalidation job, the Search runtime checks for pending invalidations before executing every request. Invalidations are processed for a maximum of 1 second. If the job completes processing all invalidations, then the server won't check again for 30 seconds. If after 1 second there are still pending invalidations, the invalidation work continues with the next request.
The Data Cache configuration file in the Search server
The Data Cache settings can be found in Search_demo.ear/xml/config/com.ibm.commerce.foundation/wc-component.xml under this node: <_config:configgrouping name="CrossTransactionCache">.
For example, you can adjust the invalidation interval (frequency to check for invalidations) with this setting:
Or change maxSeconds, to allow the invalidation work to run for longer than the default 1 second.
<_config:property name="CrossTransactionCache/invalidationJobParameters" value="localJVMOnly=true&maxSeconds=1&maxSecondsPerTransaction=0&enableRefreshRegistry=false"/>
In the invalidationJobParameters node you can also add parameters such as maxInvalidationDataIds as described in my previous post Avoiding invalidation overload after propagation.
The invalidation triggers in CommerceServer70/schema/dbtype/wcs.cacheivl.trigger.sql are used to populate the CACHEIVL table with Data Cache invalidation IDs after data changes. Alternatively, you can implement a custom method to clear caches at particular times, either by connecting to each Search server to clear the cache, or inserting "clearall" in the CACHEIVL table. To know more about clearall, see the doc for the DynacacheInvalidation job.
Out-of-the-box, the Data Cache distributed maps are not configured with a replication domain and DRS is not used. As the invalidation process runs on every Search JVM, DRS does not need to be configured.
Some important APARs
JR49920 - Slow Search server cache invalidation
JR49920 is an important fix for the Search server's Data Cache. Before this fix, if a request processing invalidations reached maxSeconds (1 second by default), the runtime would not continue processing invalidations again until after invalidationJobInterval (30 seconds). With a large number of pending invalidations, the processing would require a very long time to complete. If JR49920 is applied and a request reaches maxSeconds, invalidation processing continues with the next request instead of waiting for invalidationJobInterval. To obtain JR49920, apply the WebSphere Commerce Version 7 Fix Pack 8 Cumulative1 Interim Fix (JR50553).
If you follow these steps to create an extended wc-component.xml file: Changing REST configuration properties in the component configuration file (wc-component.xml), you will find that the changes are not picked up unless JR50925 is applied. To obtain this APAR, open a ticket with Support. As a temporary workaround, you could make the changes directly in the out-of-the-box wc-component.xml file.