Prepare to use caching in WebSphere Commerce
Preparation activities should occur before caching. These activities will only be repeated if there are major changes to the caching setup.
In the development environment servlet caching is disabled.
To enable and use servlet caching, see Configuring servlet caching topics in the WebSphere Application Server Information Center. Additional tuning information is available in theTune guide for dynamic cache and data replication service white paper.
- Cache strategy
When determining a caching strategy for WebSphere Commerce, there are several key issues to resolve.
- Environment setup
To begin caching the environment must be prepared. The cache monitor, CacheMonitor.ear application , must be installed. WebSphere Application Server provides a Dynamic Cache Monitor application for displaying cache statistics, Edge Side and disk statistics, cache entries, dependency IDs, and cache policy information. In order to inspect the contents and behavior of the WebSphere Application Server dynamic cache, you should install the WebSphere Application Server Dynamic Cache Monitor.
- Configure the dynamic cache service in cachespec.xml
The dynamic cache service is an in-memory cache system that has disk offload capability. Cacheable objects are defined the cachespec.xml file found inside the Web application archive (WAR) , Web module WEB-INF directory, or enterprise bean WEB-INF directory. A global cachespec.xml file can also be placed in the application server properties directory, but the recommended method is to place the cache configuration file with the deployment module. There is a sample cache configuration file (cachespec.sample.xml) located in the WAS_HOME/properties directory. The cachespec.dtd file is available in the application server properties directory. The following sections detail the steps required to configure dynamic caching in the cachespec.xml file.
- Allow access to encrypted parameters
Cache identifiers are based on non confidential information such as store, language, catalog, category, or product identifiers. These identifiers are typically encrypted in the URL. If the parameters are encrypted, a cache miss would result due to missing parameters for the cache ID. Therefore, in order to use these identifiers they must be made visible in the URL first. After these parameters are specified in the WebSphere Commerce configuration file for NonEncryptedParameters then a cache hit would result because they are now visible.
- Cache identifiers
When the dynamic cache service places an object in the cache, it labels it with a unique identifying string known as a cache ID. The cache ID is constructed according to <cache-id> rules specified in the <cache-entry> elements. The <cache-id> rules define how to construct cache-ids from information associated with an application server request.
- Production environments
Operating WebSphere Commerce in a production environment introduces complexities. For example, accessing cache entries that have been offloaded from memory introduces overhead associated with reading from and writing to the disk. Invalidating these entries is time consuming. Therefore, it is important to tune the cache using the available properties. By setting these values to the appropriate values, you improve the cache invalidation process. The second issue is cache replication. When WebSphere Commerce is in a clustered environment, you require a replication environment to share the cache entries between the different nodes in the environment.