Dynamic caching
In general, caching improves response time and reduces system load. Caching techniques are used to improve the performance of World Wide Web Internet applications. Most techniques cache static content (content that rarely changes) such as graphic and text files. However, many websites serve dynamic content, containing personalized information or data that changes more frequently. Caching dynamic content requires more sophisticated caching techniques, such as those provided by the WebSphere Application Server dynamic cache, a built-in service for caching and serving dynamic content.
- Servlet and JSP result cache: To cache whole pages or fragments that are generated by a servlet or a JSP page.
- Command cache: To cache command objects.
- Edge Side Include (ESI) caching: To cache, assemble, and deliver dynamic web pages at the edge of an enterprise network.
- Invalidation Support: To ensure that the content of the cache is correct. Invalidation can be rule-based, time-based, group-based, and programmatic.
- Replication support: To enable cache sharing and replication among multiple servers.
- Disk offload capability: To enable caching large amounts of data, and to preserve cache content
while the application server is stopped and restarted. Note: After the application server is restarted and the database is restored, it is recommended that you clear the disk cache by using the cache monitor. Clear the disk cache to ensure that information that is 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=true
. For more information, see DynaCacheInvalidation URL.
The caching behavior of the WebSphere Application Server
dynamic cache service is specified by cache policies that are defined by
<cache-entry>
elements in cache specification configuration XML
(cachespec.xml) files.
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 that is associated with an application server request (to execute a
servlet, JSP, or command). This definition includes how information might 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 <priorit>
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. The algorithm can also offload cached objects
with lower priority 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. Together, these IDs specify that certain
objects should be removed from the cache when certain requests (such as requests 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 that are
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 that is 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 the cachespec.xml file. When the file is updated, the old policies are replaced. Objects that are cached through the old policy file are not automatically invalidated from the cache. The objects are either reused with the new policy or eliminated from the cache through its replacement algorithm.
HCL Commerce uses WebSphere Command Caching internally such as with MemberGroupsCacheCmdImpl in the preceding cache filter; however, HCL Commerce does not support caching of commands that contain non-serializable objects.
WebSphere Application Server dynamic cache
HCL Commerce uses the WebSphere Application Server dynamic cache service for caching servlets or JSP files and commands that extend from the WebSphere Application Server CacheableCommand interface. The dynamic cache service, servlet caching, and disk offload are enabled by default, during the creation of an HCL Commerce instance.
Limitations of dynamic caching
- When you create a catalog entry or move a catalog entry from one category to another in the Management Center, the catalog entry would not show up on the storefront.
- When you create a category in the Management Center, the category would not show up on the storefront.
- When you update a child object in the Management Center, the parent object cache entry is not automatically invalidated. For example, when you update a catalog entry in the Management Center, the category display page does not reflect the updates in the storefront.