Caching

Dynamic caching

•     Caching in general improves response time and reduces system load.
•     DynaCache is an example of a server-side caching mechanism. It is a form of HashTable.
•     DynaCache is configured to store objects, and later, based on some data matching rules
•     DynaCache  retrieves the matching objects and serves them from the cache.
•     Caching rules are defined in a configuration file called cachespec.xml.
•     Caches are stored in the JVM heap memory
•     If cache is full then dyna cache supports disc offload if enabled and when required

Kinds of caching

•     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.

DynaCaching
 
The caching behavior is specified by cache policies defined in the configuration file (cachespec.xml). The WebSphere dynamic cache service parses the cachespec.xml file during startup, and extracts a set of configuration parameters from each <cache-entry> element.
    
<cache-entry>

 <class>servlet | command</class> This indicates that the cache policy defines caching rules for a servlet or a JavaServer Page (JSP) deployed in the WebSphere Application Server servlet engine.

 <name>classname</name> It specifies the fully qualified class name of the command or servlet.

<property name="key">value</property> 

Property	Description
consume-subfragments	If true, the cache will include all the content from all fragments in its cache entry, resulting in one large cache entry that has no includes or forwards. This saves a significant amount of application server processing, but is typically only useful when the external HTTP request contains all the information needed to determine the entire list of included fragments.
save-attributes	If false, the request attributes are not saved with the cache entry.
store-cookies	If false, the request cookies are not saved with the cache entry.
do-not-consume	If true, the fragment will not be consumed by the parent entry with the consume-subfragments property.
persist-to-disk	If false, the cache entry is not written to the disk when an overflow or server stop occurs.
do-not-cache	If true, the entry is neither cached nor consumed by its parent.
Sharing-policy	This determines the sharing characteristics of entries that are created from this object. not-shared(default): Cache entries are not shared among different application servers shared-push: Cache entries are automatically shared to the dynamic caches in other application servers. Each cache has a copy of the entry at the time it is created. shared-pull(not recommended): Cache entries are shared between application servers on demand shared-push-pull: Cache entries for this object are shared between application servers on demand. When an application server generates a cache entry, it broadcasts the cache ID of the created entry to all cooperating application servers. Each server then knows whether an entry exists for any given cache ID. On a given request for that entry, the application server knows whether to generate the entry or pull it from somewhere else.

 

<cache-id> Cache ID is a unique ID to cache an object. <cache-id> element defines a rule for caching an object. It consists of the following subelements.

    <cache-id>
       component*| timeout? | inactivity? | priority? | property* | idgenerator? | metadatagenerator?
    </cache-id>      

<component> Portion of the cache ID using the “id” attribute

<required> This says whether the component is required to form a valid cache

<timeout> This specifies an absolute time-to-live (TTL) value for the cache entry.
   
<dependency-id> Specifies additional cache identifiers that associate multiple cache entries to the same group identifier.
     
<invalidation> Invalidation IDs are generated according to rules specified by <invalidation> elements within <cache-entry> elements. When a request matching a <cache-entry> element is received, its generated invalidation IDs are matched against the dependency IDs previously associated with cached objects. Cached objects with an associated dependency ID that is the same as one of the generated invalidation IDs are invalidate

More on Cache Invalidation
How to install Cache Monitor ?