REST Caching & Invalidation
This Blog describes the Rest caching implementation of the WebSphere Commerce (WCS) component. WebSphere Commerce uses REST services to provide a framework to develop RESTful applications. REST services use both server-side caching and client-side caching. Server-side caching is achieved by using dynacache, and client-side caching is achieved by using cache directives in the response header. There is not a golden rule for caching configuration in WCS. There are so many factors on which the caching configuration depends e.g. Number of JVMs,Type of cache,use interval & frequency, Available space and memory. Here I am going to talk about the cache configuration and invalidation process.
For more caching strategy please click the below link.
Out of the box, REST traffic can be cached both server-side and client-side. Server-side caching is achieved by using dynacache, and client-side caching by using cache directives in the response header.
This section describes server-side REST caching. It assumes knowledge of underlying WCS caching capabilities, which are described in the Knowledge Centre.
Requests that can be cached are defined in the cachespec.xml file within the relevant WAR (web archive) file. For REST requests (starting /wcs/resources) this is Rest.war/WEB-INF/cachespec.xml. For REST Search requests (starting /search/resources) this is Search-Rest.war/WEB-INF/cachespec.xml.
cachespec.xml defines what is cached but not where it is cached. The objects are cached in the “dynacache” component of each WCS JVM (more strictly: dynacache is a component of WebSphere Application Server (WAS), WCS is an application running on WAS). The cache is known as the “servlet cache”, “base cache” or “baseCache”. The baseCache for the REST JVMs is different from that for the REST Search JVMs.
Entries can be individually invalidated in a number of ways as described below.
All cached entries have an associated timeout, as specified in the definitions provided in the cachespec.xml. Thus, for example, a specific price REST call is created with an 8 hour timeout. Regardless of how often this entry is accessed, it will be removed from the cache 8 hours after it has been created. (If the cache is full it could be deleted earlier than this.)
An inactivity timeout value can also be configured, allowing the entry to be removed if it has not been accessed for a configured time period.
Each definition has zero or more dependency IDs associated with it. When a cached entry is invalidated other cache entries belonging to its set of dependency IDs are also invalidated.
The Cache Monitor can be used to remove entries. It is possible to remove individual entries, a set of entries based on a dependency ID, or remove all entries.
Entries can be removed by dynacache APIs.
When database data is changed, database triggers (created by WCS as part of installation) write entries to the DB2 CACHEIVL table. This contains a set of instructions defining what cached entries need to be removed to maintain data consistency. This technique is used to invalidate data in both the base cache and the data cache (customized cache).
As an example of how this works, consider the price REST call, suppose it is for store ID 12345 and part number 67890. When the cache entry is created it will have dependency ID Price:storeId:partNumber:12345:67890.
How CACHEIVL invalidation works
- The DB2 OFFERPRICE database table contains the price detail for all of the products. When a change is made to a price for this item, the OFFERPRICE table for that row is updated. This means that the data in the base cache of all JVMs is now out of date and needs to be invalidated.
- A database trigger for this table exists When the OFFERPRICE row is updated the trigger causes a row to be written to the CACHEIVL table with value Price:storeId:partNumber:12345:67890.
- According to the scheduled defined in your project, the DynaCacheInvalidation scheduled job runs on one of the JVMs. This processes all of the CACHEIVL entries that have been written since the last time this job ran. When it processes the entry for Price:storeId:partNumber:12345:67890 it uses this as a dependency ID and invalidates all cache entries in this JVM matching this dependency ID.
- This invalidation is only local to this JVM. Entries in other JVMs are then invalidated by the WebSphere DRS (Data Replication Service) component. All JVMs have been configured to belong to the same replication domain. DRS broadcasts messages to these JVMs telling them to remove the entry from their caches. In this way data is kept consistent across all WCS JVMs and the database.
The base cache can be emptied by various means, including the Cache Monitor and by placing a “clearall” entry in CACHEIVL
For more details on Rest Services caching , visit https://www.ibm.com/support/knowledgecenter/SSZLC2_9.0.0/com.ibm.commerce.webservices.doc/refs/rwvrestcache.htm