Types of caching | WAS Dynamic cache
Dynamic caching
The dynamic cache service includes:
Servlet or JSP result cache Cache pages or fragments generated by servlets and JSPs. Command cache Cache command objects. Edge Side Includes cache Cache, assemble, and deliver dynamic Web pages at the edge of an enterprise network. Invalidation support Invalidation can be...
- time based
- group based
- programmatic
Replication support Enable cache sharing and replication among multiple servers. Disk offload capability Enable caching large amounts of data, and to preserve cache content while the application server is stopped and restarted. After the application server is restarted and the database restored, IBM recommends that you clear the disk cache using the cache monitor. This will ensure that information that has become invalid for the new database is removed.
Use the cache monitor to clear the cache or, alternatively, use the following URL:
http://host_name/path/DynaCacheInvalidation?clear=trueThe caching behavior of the WebSphere Application Server dynamic cache service is specified by cache policies defined by <cache-entry> elements in cachespec.xml.
As the dynamic cache service places objects in the cache, it labels them with unique identifying strings (cache IDs) constructed according to <cache-id> rules specified in the <cache-entry> elements. Once an object with a particular cache-id is in the cache, a subsequent request for an object with the same cache-id is served from the cache (a cache hit). The <cache-id> rules define how to construct cache-ids from information associated with an application server request (to execute a Servlet, JSP, or command), including how information may be obtained programmatically from CacheableCommand objects.
Cached objects are removed from the cache according to information provided in their <cache-entry> elements, such as the <timeout>, <priority>, and <invalidation> elements.
The <timeout> and <priority> elements configure expiry and eviction policies. When the available cache memory is full, a least recently used (LRU) caching algorithm removes cached objects with lower priority, or offloads them to disk if the disk offload capability is enabled, before those with higher priority.
The <dependency-id> and <invalidation> elements define rules that generate dependency IDs and invalidation IDs, which together specify that certain objects should be removed from the cache when certain requests (such as those that update cached information) are processed. When an object is cached, its generated dependency IDs are associated with it in the cache. When a request causes invalidation IDs to be generated, all objects associated with those invalidation IDs are removed from the cache.
The <inactivity> element 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. The value is the amount of time, in seconds, to keep the cache entry in the cache after the last cache hit.
The dynamic cache service responds to changes in cachespec.xml. When the file is updated, the old policies are replaced. Objects cached through the old policy file are not automatically invalidated from the cache. They are either reused with the new policy or eliminated from the cache through its replacement algorithm.
WebSphere Commerce uses WebSphere command caching internally, such as with MemberGroupsCacheCmdImpl in the preceding cache filter. However, WebSphere Commerce does not support caching of commands that contain non-serializable objects.
xxxx