Cache invalidation
In order to maintain the relevance of cached data, based on time, user or other variables, the data will have to be invalidated or removed from the cache. Dynacache provides different methods for performing cache invalidation.
Time based invalidation
Time-based invalidation is useful when the cache entries cannot be invalidated by any other mechanism, or they should be refreshed after a set period. This method can be accomplished by specifying the <timeout>value</timeout> sub-element with a cache-entry in the cachespec.xml file. Value is the amount of time, in seconds, the cache entry is kept in the cache. The default value for this element is 0, which indicates this entry never expires. For more information about how to use the <timeout> tag see Configure cacheable objects with the cachespec.xml file.
An example in which time-based invalidation makes sense to use is caching of a e-Marketing Spot. In general e-Marketing Spots should not be cached because the page output is generated dynamically based on personalized data. But in the case that the store admin is willing to sacrifice function for performance, then the e-Marketing spot JSP pages can be cached with a timeout sub-element, so that the output can be reused for a certain period of time.
There is also an inactivity subelement which is used to specify a time-to-live (TTL) value for the cache entry based on the last time that the cache entry was accessed. It is a subelement of the cache-id element. <inactivity>value<inactivity> where value is the amount of time, in seconds, to keep the cache entry in the cache after the last cache hit. This is especially useful for user dependent cache entries where the an average user session duration can be specified as an inactivity timeout.
Command based invalidation
Invalidation occurs upon execution of a command, based on invalidation rules, that extends from the WebSphere Commerce Command Framework API. Invalidation IDs for command-based invalidation are constructed based on methods and fields provided by the commands.
To allow a command call to be intercepted by the dynamic cache, the command must be written to the WebSphere Command Framework within its implementation class extending from CacheableCommandImpl (in the com.ibm.websphere.command package). To simplify command writing for command-based invalidation, WebSphere Commerce has updated the abstract classes, ControllerCommandImpl and TaskCommandImpl. They extend from CacheableCommandImpl so that any commands extend from these abstract classes would also extend from CacheableCommandImpl, and therefore, be eligible for command-based invalidation.
When building the command-based invalidation policies in cachespec.xml, keep in mind the following restrictions:
- Only the methods invoked by the command that return the input instance variables can be used in the method component.
- All the methods used to construct the invalidation IDs, must be provided in the command interface and be implemented.
- The request attributes component type cannot be used.
Dynacache API and CACHEIVL table invalidation
WebSphere Application Server dynamic caching provides the following Java classes to support programmatic invalidation
- com.ibm.websphere.cache.DistributedMap
- com.ibm.wsspi.cache.Cache
- com.ibm.websphere.cache.Cache
WebSphere Commerce provides a DynaCacheInvalidation command, which is called by the scheduler periodically to process the records in the CACHEIVL table and call the above WebSphere Application Server dynamic cache Java classes to invalidate the specified cache entries. By default, the schedule interval is every ten minutes.
Group based invalidation
Use dependency trees we can to create conceptual groupings of your cache-entries, and invalidate based on those groups.
We can specify additional cache group identifiers to associate multiple cache entries the same group identifier in cachespec.xml. There is no limit on the number of such identifiers -- dependency IDs, that can be defined in a cache entry. We can define more than one dependency ID on the same cache entry and the same dependency identifier can be reused on another cache entry. This mechanism provides a convenient way to remove all related cache entries at the same time by means of a single rule.
The following shows an example in which the same dependency ID and storeId, has been defined on each of the catalog page cache entries. Also, at the end, an invalidation rule is provided in which the invalidation ID is generated in a way that maps to that of the dependency ID when the rule intercepts the command call to StoreStyleUpdateCmd. At execution time, after dynamic cache generates the invalidation ID, it will compare the ID to each of the dependency IDs for the same identifier and value from the cache entries. All catalog page cache entries that are grouped under the dependency ID will be removed.
Example of group-based invalidation:
<cache-entry>
<class>servlet</class>
<name>/Tooltech/ShoppingArea/CatalogSection/CategorySubsection/CachedStoreCatalogDisplay.jsp</name>
. . .
<dependency-id>storeId
<component id="storeId"
type="parameter">
<required>true</required>
</component>
</dependency-id>
</cache-entry>
<cache-entry>
<class>servlet</class>
<name>/Tooltech/ShoppingArea/CatalogSection/CategorySubsection/CachedTopCategoriesDisplay.jsp</name>
. . .
<dependency-id>storeId
<component id="storeId" type="parameter">
<required>true</required>
</component>
</dependency-id>
</cache-entry>
<cache-entry>
<class>servlet</class>
<name>/Tooltech/ShoppingArea/CatalogSection/CategorySubsection/CachedCategoryDisplay.jsp</name>
<name>/Tooltech/ShoppingArea/CatalogSection/CategorySubsection/CategoriesRouter.jsp</name>
. . .
<dependency-id>storeId
<component id="storeId" type="parameter">
<required>true</required>
</component>
</dependency-id>
</cache-entry>
<cache-entry>
<class>servlet</class>
<name>/Tooltech/ShoppingArea/CatalogSection/CategorySubsection/CachedProductDisplay.jsp</name>
<name>/Tooltech/ShoppingArea/CatalogSection/CategorySubsection/CachedItemDisplay.jsp</name>
. . .
<dependency-id>storeId
<component id="storeId" type="parameter">
<required>true</required>
</component>
</dependency-id>
</cache-entry>
<cache-entry>
<class>command</class>
<name>com.ibm.commerce.tools.devtools.store.commands.StoreStyleUpdateCmdImpl</name>
. . .
<invalidation>storeId
<component id="getStoreId" type="method">
<required>true</required>
</component>
</invalidation>
</cache-entry>
See
- Writing commands for command-based invalidation
- Defining the invalidation policies in cachespec.xml
- Adding sample invalidation policies to the store's cachespec.xml file
- Enable cache monitoring
- Removing cache entries through the Cache Monitor
- Cache invalidation using Kafka and ZooKeeper
Related concepts
Caching strategy
Dynamic caching
Dynamic caching considerations with JSTL
Related reference
DynaCacheInvalidation URL
Related information:
