Introduction
Cache invalidation is one of the key and tedious part of software development. It is really important that we purge the invalid data out of the cache at the right time so that the customers always see the updated content. After FEP7 IBM has segregated the websphere commerce application into two. WCS and Search. We use DynaCacheInvalidation command to invalidate the cache.
Caching
It is now possible to cache the data in Search as well as WCS dynacache as they are placed in different servers. We can make changes to the cachespec.xml in these applications and define the caching strategy. As both the caches are used we should make sure that whenever the data is updated the cache entries must be cleared in WCS and search in the right order.
Cache invalidation
In WCS, OOB uses DynacacheinvalidationCmd for clearing the cache entries. As this is a scheduler command, it runs inside the WCS JVM and will clear the cache entries from WCS dynacache. For better performance we can cache the data at search as well.
For Search, OOB uses a filter. Every search request will go through this filter and it will invalidate the relevant cache entires as per the dependency id and insert time in CAHCHEIVL table. The name of the filter is RestInvalidationFilter. The filter will look at the value of "CrossTransactionCache/invalidationJobInterval" in wc-component.xml under com.ibm.commerce.foundation folder. If the value is 30, it means the filter will trigger the cache invalidation every 30 seconds.
Why Cross transactional invalidations are required betweens WCS and Search?
For example the jsps can be cached in WCS dynacache and search responses can be cached in Search dynacache. In this scenario we need both the caches to be cleared in the right fashion. Let us take a product page(say product.jsp) for example. To show the product page we make a /detailsByProductId search call to get the product data. The page is cached in commerce and the search response is cached in Search JVM. If any of the product data changes we need to invalidate both caches. The search cache has to be invalidated before the WCS cache because in case if commerce cache entry is cleared (where as search is not yet cleared) and it makes a call to search for getting the details, the search will respond with old data.
How to trigger invalidation between apps
There are many approaches to achieve it. One of it is to customise the DynaCacheInvalidationCmd and to make a search rest call in it.
2. Change the DynaCaheInvalidationCmd implementation. Extend the OOB command and make sure we call the above rest call before we trigger the WCS invalidations. That will make sure that the search cache is invalidated prior to WCS cache.
3. Extend the wc-component.xml and override the CrossTransactionCache/invalidationJobInterval value to -1 so that the filter will not invalidate on its own. Alternatively the filter can be removed from web.xml as well.
Clustered environment: In a clustered environments there were issues with cache getting replicated across cells. One of the way to fix it is to schedule two different instances of DynaCacheInvalidation job on one server in each cell using the JVM property com.ibm.commerce.scheduler.SchedulerHostName
Cache invalidation is one of the key and tedious part of software development. It is really important that we purge the invalid data out of the cache at the right time so that the customers always see the updated content. After FEP7 IBM has segregated the websphere commerce application into two. WCS and Search. We use DynaCacheInvalidation command to invalidate the cache.
Caching
It is now possible to cache the data in Search as well as WCS dynacache as they are placed in different servers. We can make changes to the cachespec.xml in these applications and define the caching strategy. As both the caches are used we should make sure that whenever the data is updated the cache entries must be cleared in WCS and search in the right order.
Cache invalidation
In WCS, OOB uses DynacacheinvalidationCmd for clearing the cache entries. As this is a scheduler command, it runs inside the WCS JVM and will clear the cache entries from WCS dynacache. For better performance we can cache the data at search as well.
For Search, OOB uses a filter. Every search request will go through this filter and it will invalidate the relevant cache entires as per the dependency id and insert time in CAHCHEIVL table. The name of the filter is RestInvalidationFilter. The filter will look at the value of "CrossTransactionCache/invalidationJobInterval" in wc-component.xml under com.ibm.commerce.foundation folder. If the value is 30, it means the filter will trigger the cache invalidation every 30 seconds.
Why Cross transactional invalidations are required betweens WCS and Search?
For example the jsps can be cached in WCS dynacache and search responses can be cached in Search dynacache. In this scenario we need both the caches to be cleared in the right fashion. Let us take a product page(say product.jsp) for example. To show the product page we make a /detailsByProductId search call to get the product data. The page is cached in commerce and the search response is cached in Search JVM. If any of the product data changes we need to invalidate both caches. The search cache has to be invalidated before the WCS cache because in case if commerce cache entry is cleared (where as search is not yet cleared) and it makes a call to search for getting the details, the search will respond with old data.
How to trigger invalidation between apps
There are many approaches to achieve it. One of it is to customise the DynaCacheInvalidationCmd and to make a search rest call in it.
1. Create a new rest in service in search server and implement it in the same way as what the filter currently does. The changes where it looks for component configuration and all can be overridden. So the rest can call the OOB LocalJVMDynaCacheInvalidationHelper (as the OOB rest filter does). It will automatically remember the last invalidation time and will check for the cacheivl records after that.
2. Change the DynaCaheInvalidationCmd implementation. Extend the OOB command and make sure we call the above rest call before we trigger the WCS invalidations. That will make sure that the search cache is invalidated prior to WCS cache.
3. Extend the wc-component.xml and override the CrossTransactionCache/invalidationJobInterval value to -1 so that the filter will not invalidate on its own. Alternatively the filter can be removed from web.xml as well.
Clustered environment: In a clustered environments there were issues with cache getting replicated across cells. One of the way to fix it is to schedule two different instances of DynaCacheInvalidation job on one server in each cell using the JVM property com.ibm.commerce.scheduler.SchedulerHostName
