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

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

Using 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>