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. There are four methods to invalidate the cache.

• Time based invalidation

• Command based invalidation

• Dynacache API and CACHEIVL table invalidation

• Group based 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 on how to use the <timeout> tag see Configuring 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 polices 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 that are 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

WAS dynamic caching provides the following APIs to support programmatic invalidation:

• com.ibm.websphere.cache.invalidateById

• com.ibm.websphere.cache.invalidateByTemplate

• com.ibm.websphere.cache.clear

WebSphere Commerce also provides a DynaCacheInvalidation command, which is called by the scheduler periodically to process the records in the CACHEIVL table. It then calls the WAS dynamic cache invalidation APIs to invalidate the specified cache entries. By default, the schedule interval is every ten minutes.

The rules for the DynaCacheInvalidation command when processing the CACHEIVL table are as follows:

• The "clearall" string value in the TEMPLATE or DATA_ID columns of the CACHEIVL table is used by DynaCacheInvalidation to clear the cache by dynamic cache invalidation API (clear).

• If the TEMPLATE column is set, then the DynaCacheInvalidation command calls the dynamic cache invalidation API (invalidateByTemplate) and uses the name as the template ID. If the "clearall" string value (which is case insensitive) is found in TEMPLATE column, then the DATA_ID column is ignored and the DynaCacheInvalidation command will clear cache. If the TEMPLATE column is not empty, the command invalidates by the template ID, ignoring the DATA_ID column.

• If the DATA_ID column is set and the template name is not set, then the DynaCacheInvalidation command calls the dynamic cache invalidation API (invalidateById) and uses the DATA_ID as the ID. If the TEMPLATE column is empty and the "clearall" string value is found in the DATA_ID column, then the command clears the cache.

• When the dynamic cache invalidation API is called, it invalidates the cache entries.

 

Group based invalidation

Use dependency trees you can to create conceptual groupings of your cache-entries, and invalidate based on those groups.

You 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. You 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>

 

Related tasks

Tutorial: Invalidating cache

 

Related Reference

Caching defaults
DynaCacheInvalidation URL