Chapter 2. WebSphere Commerce V5.6 Overview 33
Draft Document for Review July 28, 2004 7:33 pm 6320ch_sum_of_changes.fm
2.6.15 Caching
Server-side caching improves response time and reduces system load thus
boosting performance and reducing infrastructure costs. The WebSphere
Commerce servlet and page caching is now part of the WebSphere Application
Server dynamic caching infrastructure (Dynacache).
Dynacache
WebSphere Application Server offers a built-in dynamic cache service for serving
dynamic content and caching data. There is no time-consuming installation and
integration work needed to activate. DynaCache can be viewed as a
sophisticated hash table, where Java object store and retrieve commands are
executed in memory.
Some of the features of WebSphere Application Server dynamic cache
(DynaCache) are servlet/JSP result cache, replication support, invalidation
support, Edge of Network caching support and tools to assist in configuring the
cache and monitoring runtime.
The cache policy is defined by a policy based cachespec.xml file. Some of the
cacheable objects defined by this policy include: servlet/JSP files, command
beans, Web services, cache and dependency ID's generation rules, replication
policy, invalidation rules, time-out, and priority for least recently used eviction
algorithm. The cachespec.xml file resides inside the Web Module WEB-INF
directory and a copy of this file can be placed in the application server properties
directory. It is also flexible and modifiable at runtime.
This type of cache also supports fragment caching. This is the ability to cache
portions of a page. For example, instead of caching a full page MyJSP.jsp, you
can choose to cache fragments, which can include the header, footer, sidebar
and the main area. All of these fragments are dynamic pages that are part of the
larger dynamic page for MyJSP.jsp. There is a performance gain in fragment
caching but it is not dramatic because the non-cached parts of the page
determine the performance.
Replication support enables cache sharing (central cache) and replication (local
cache) among multiple servers and tiers. Replication uses a built-in high
performance JMS broker messaging system as its underlying engine for data
replication. In local cache replication among server, if there is a update to the
cache, the cache server publishes a message regarding the change to the
messaging broker and the changes are automatically replicated to the other
servers.
Some factors to consider for fragment caching include reusability, invalidation
and variations. Fragments should be able to be reused frequently enough by