Use the dynamic cache service

Cache the output of servlets, web services, and WAS commands into JVM memory.

Cache policies for applications, defined in cachespec.xml files, define rules for what responses to cache, and the amount of time the responses should be held in the cache.

The dynamic cache service is enabled by default. To configure the default cache instance...

Servers | Server Types | WebSphere application servers | server_name | Container services | Dynamic cache service

Example

This example configures the dynamic cache service with a cachespec.xml file, showing the use of the cache ID generation rules, dependency IDs, and invalidation rules.

Suppose that a servlet manages a simple news site. This servlet uses the query parameter "action" to determine if the request views (query parameter "view") news or updates (query parameter "update") news (used by the administrator). Another query parameter "category" selects the news category. Suppose that this site supports an optional customized layout stored in the user's session using the attribute name "layout". Here are example URL requests to this servlet:

Request	Description
http://host/webapp/newscontroller?action=view&category=sports	Returns News page for the sports category
http://host/webapp/newscontroller?action=view&category=money	Returns News page for the money category
http://host/webapp/newscontroller?action=update&category=fashion	Allow administrator to update news in the fashion category

The following steps illustrate how to configure the dynamic cache service for this example with the cachespec.xml file:

1. Define the <cache-entry> elements necessary to identify the servlet

   In this case, the URI for the servlet is "newscontroller", so this is the cache-entry <name> element. Because this example caches a servlet or JSP file, the cache entry class is "servlet".

   <cache-entry> 
       <name> /newscontroller </name>
       <class>servlet  </class>   
   </cache-entry>
   

2. Define cache ID generation rules.

   This servlet caches only when action=view, so one component of the cache ID is the parameter "action" when the value equals "view". The news category is also an essential part of the cache ID. The optional session attribute for the user's layout is included in the cache ID. The cache entry is now:

   <cache-entry> 
       <name> /newscontroller </name>
       <class>servlet  </class> 
       <cache-id>
           <component id="action" type="parameter">
          <value>view</value>
            < required>true</ required>
         </component>
         <component id="category" type="parameter">
            < required>true</ required>
         </component>
         <component id="layout" type="session">
            < required>false</ required>
         </component>
    </cache-id>
   </cache-entry>

3. Define dependency ID rules. For this servlet, a dependency ID is added for the category. Later, when the category is invalidated due to an update event, all views of that news category are invalidated. Following is an example of the cache entry after adding the dependency ID:

   <cache-entry>   <name>newscontroller </name>
    <class>servlet  </class>    <cache-id>
     <component id="action" type="parameter">
      <value>view</value>
      < required>true</ required>
     </component>
     <component id="category" type="parameter">
      < required>true</ required>
     </component>
     <component id="layout" type="session">
      < required>false</ required>
     </component>
    </cache-id>
    <dependency-id>category
     <component id="category" type="parameter">
      < required>true</ required>
     </component>
    </dependency-id>
   </cache-entry>

4. Define invalidation rules. Because a category dependency ID is already defined, define an invalidation rule to invalidate the category when action=update. To incorporate the conditional logic, add "ignore-value" components into the invalidation rule. These components do not add to the output of the invalidation ID, but only determine whether or not the invalidation ID creates and runs. The final cache-entry now looks like the following:

   <cache-entry>   <name>newscontroller </name>
    <class>servlet  </class>    <cache-id>
     <component id="action" type="parameter">
      <value>view</value>
      < required>true</ required>
     </component>
     <component id="category" type="parameter">
      < required>true</ required>
     </component>
     <component id="layout" type="session">
      < required>false</ required>
     </component>
    </cache-id>
    <dependency-id>category
     <component id="category" type="parameter">
      < required>true</ required>
     </component>
    </dependency-id>
    <invalidation>category
     <component id="action" type="parameter" ignore-value="true">
      <value>update</value>
      < required>true</ required>
     </component>
     <component id="category" type="parameter">
      < required>true</ required>
        </component>
    </invalidation>
   </cache-entry>

What to do next

We might want to enable dynamic cache disk offload. This option moves cache entries that are expired from memory to disk for potential future access. Refer to the Configuring dynamic cache disk offload for more information about enabling disk offload.

Subtopics

1. Dynamic cache service settings
2. Configure dynamic cache (DynaCache) to use the WebSphere eXtreme Scale dynamic cache provider
3. Configure servlet caching
4. Configure portlet fragment caching
5. Configure portlet fragment caching with wsadmin.sh
6. Configure caching for Struts and Tiles applications
7. Configure dynamic cache disk offload
8. Configure Edge Side Include caching
9. Configure external cache groups

Related tasks

Configure cache replication

Task overview: Use the dynamic cache service to improve performance

Use the DistributedMap and DistributedObjectCache interfaces for the dynamic cache

Configure cacheable objects with the cachespec.xml file