Administer > Dynamic caching


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

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 polices in cachespec.xml, keep in mind the following restrictions:

See also: Trigger-based JSP cache invalidation


Dynacache API and CACHEIVL table invalidation

WebSphere Application Server dynamic caching provides the following APIs to support programmatic invalidation:

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 WebSphere Application Server 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...


Group based invalidation

Use dependency trees you can to create conceptual groupings of the 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>


See also

  1. Perform trigger-based JSP cache invalidation using the Madisons starter store
  2. Write commands for command-based invalidation
  3. Define the invalidation policies in cachespec.xml
  4. Add sample invalidation policies to the store's cachespec.xml file
  5. Remove cache entries through the Cache Monitor
  6. Enable the Dynamic Cache Monitor


Related reference

Cache defaults

DynaCacheInvalidation URL


+

Search Tips   |   Advanced Search