2.4 DynaCache technical overview
Think of DynaCache as a sophisticated Java hashtable. The code used to provide the in-memory cache services extends the Java Dictionary class, which is the abstract parent of Hashtable. You configure DynaCache to store objects, and later, based on some data matching rules, DynaCache retrieves those objects and serves them from its cache. Caching rules are stored in a configuration file called cachespec.xml. Single or multiple caches are supported. Caches are stored in the JVM heap memory and DynaCache supports overflow to disk if enabled and when required.
The system administrator has some degree of control over what is placed in memory and what (if anything) overflows to disk via configuration settings. DynaCache also calls a least recently used (LRU) algorithm during the item selection process for memory-based item eviction or overflow. The LRU algorithm consults with a user-specified cache entry priority number before the evictee is chosen. Higher numbered items stay in memory longer.
Disk offload of cache entries from memory occurs when the memory cache fills up or when the server is in the process of performing a normal, administrator-directed shut down and the "FlushToDiskOnStop" property is enabled. Upon a server restart, requests for cache entries are fulfilled by reloading the saved disk data into memory.
DynaCache removes stale cache items, both as individuals or dependent, related groups. The process of removing these items is called invalidation. DynaCache creates a user-defined, unique "key" to store and retrieve cache items and a second, optional, shared group key for group invalidation. DynaCache also provides an API for developers to call invalidation as a runtime function.
DynaCache is supported in WebSphere clustered environments using the Distributed Replication Service.
A purpose-built DynaCache monitoring application can be installed from...
<WAS 6 Root>/installableapps
...found in every installation of the application server. You can use this application for:
| 
|
| Cache administration |
|
|
|
| Cachespec.xml rule debugging |
|
|
|
| Statistics gathering |
|
|
|
| Monitoring of the cache |
|
|
|
| Invalidating the cache |
Each cache instance is independent of and not affected by any other cache instances.
Applications running on an application server can access cache instances on other application servers as long as they are part of the same replication domain. WebSphere Application Server V5.1 DynaCache provided a feature called cache instance. In V6, this feature was extended and now provides two types of cache instances: servlet cache instance and object cache instance.
The servlet cache instance stores servlets, JSPs, Struts, Tiles, command objects and SOAP requests. It allows applications like WebSphere Portal Server and WebSphere Commerce to store data in separate caches.
The object cache instance is used to store, distribute, and share Java objects. The DistributedObjectCache and DistributedMap APIs are provided so the applications can interact with the object cache instances.
The DistributedMap and DistributedObjectCache interfaces are simple interfaces for the DynaCache. Using these interfaces, J2EE applications and system components can cache and share Java objects by storing a reference to the object in the cache. The default DynaCache instance is created if the DynaCache service is enabled in the Administrative Console. This default instance is bound to the global Java Naming and Directory Interface™ (JNDI) namespace using the name services/cache/distributedmap.
Figure 2-8 WebSphere Application Server DynaCache overview
The DynaCache service works within an application server Java Virtual Machine (JVM), intercepting calls to cacheable objects. For example, it intercepts calls to the servlet service() method or a Java command performExecute() method, and either stores the output of the object to the cache or serves the content of the object from the DynaCache. For a servlet, the resulting cache entry contains the output or the side effects of the invocation, like calls to other servlets or JSP files, or both.
The DynaCache loads and builds a caching policy for each cacheable object from its configuration cachespec.xml file located under the WEB-INF directory. This policy defines a set of rules specifying when and how to cache an object (that is, based on certain parameters and arguments), and how to set up dependency relationships for individual or group removal of entries in the cache.
Each data request (meaning any invocation of a cacheable servlet, JSP, Web service, or other object) is associated with a set of input parameters that are combined to form a unique key, called a cache identifier or cache-id. A key policy defines which cache identifiers result in a cacheable response. If a subsequent request generates the same key, the response is served from the cache. If a unique key does not match any of the rules, the response for the request is not cached.