This text describes how to perform a complete cache invalidation in WebSphere Commerce 7 for single server and cluster configurations.
What may seem as a straightforward task, complete invalidation of server’s or cluster’s dynamic cache requires understanding of cache instances and invalidation replication to be performed properly.
WebSphere dynamic cache stores data in the following application accessible cache instance types:
- Servlet type cache instance, used to store the output of servlets, commands, and JavaServer Pages (JSP). For servlet cache to work, it must be enabled in the server’s Web container (the setting is also accessible from the Dynamic cache service screen, see below).
- Object type cache instance, used by J2EE applications to store, distribute, and share objects. You can use the DistributedMap or DistributedObjectCache interfaces in the com.ibm.websphere.cache package to programmatically access them.
Enable the Dynamic cache service to enable caching (Servers > Application servers > server_name > Container services > Dynamic cache service). Each cache instance is independent of and not affected by any other cache instance. Applications running in an application server can access cache instances on other application servers as long as they are part of the same replication domain (Source, p39).
WebSphere application server contains one default instance of each type:
- baseCache default servlet type cache instance (JNDI name: services/cache/basecache)
- DistributedMap object type cache instance (JNDI name: services/cache/distributedmap)
It is possible to define additional cache instances of each type for reasons such as performance tuning and ease of coding. baseCache instance stores all content which does not have the <cache-instance> element specified in the cachespec.xml file. In Commerce, all servlet cache type content is stored in the baseCache instance.
In cluster configurations, it is important to have invalidations replicated between cluster members. Invalidations are always replicated between cluster members which are part of the same replication domain (regardless of the Replication type) for cache instances which have replication enabled. Replication of the default cache instances is enabled in the Dynamic cache service screen -> Enable cache replication. For additionally configured cache instances, replication must be enabled in the cacheinstances.properties file: cacheinstances.properties file
The scope on which the cache instance is defined (server, cluster, ...) does not affect invalidation replication; it only affects visibility of the cache instance by the applications.
Complete invalidation of Commerce cache
To completely invalidate Commerce cache, we must invalidate the baseCache and Commerce specific object cache instances on one cluster member which must be part of cluster’s replication domain. If we have more than one replication domain configured, we must invalidate cache on one member of each replication domain.
Cache can be invalidated manually via the Extended Cache Monitor application which, unlike the included Cache Monitor application, lists both servlet and object type cache instances on the drop down menu. The Cache Monitor application only lists the servlet cache instance types. An alternative to the Extended Cache Monitor application is the Commerce DynaCacheInvalidation command; with proper parameters it will invalidate all relevant cache instances. It can be executed immediately using the Commerce job scheduler by an administrator as follows:
The job can also be invoked directly using the following URL (browser must have a valid admin login cookie for the URL to work):
Log in to the Commerce server as admin (a console or store page will do; the aim is to have the login cookie), then use the URL (remember to keep the same host and transport type). After the command executes, you may receive an error message that a resource does not exist - that's because this command doesn't have a result view defined.
If the command is scheduled, the CACHEIVL.DATAID value is clearall.
Thanks to Kevin Ortega and Robert Dunn for explaining caching details.
14th November 2014: Added DynaCacheInvalidation URL usage details.
1st June 2016: services/cache/defaultdistributedmap is actually services/cache/distributedmap. Additional clarification was made about scheduler job execution.