Use the dynamic cache service
Use the dynamic cache service to improve application performance by caching the output of servlets, web services, and WebSphere Application Server commands into memory.
Develop a cache policy for the application. The cache policy defines rules for what responses to cache and the amount of time the responses should be held in the cache. Refer to the Configuring cacheable objects with the cachespec.xml file article for more information.
The dynamic cache service is enabled by default. We can configure the default cache instance, as follows:
- Click Servers > Server Types > WebSphere application servers > server_name > Container services > Dynamic cache service.
- Configure the default cache instance or follow the links to enable servlet or portlet caching. Refer to the Dynamic cache service settings article for more information about default cache settings.
Example
This example puts all of the steps together for configuring the dynamic cache service with the 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:
- http://yourhost/yourwebapp/newscontroller?action=view&category=sports
Returns a news page for the sports category
- http://yourhost/yourwebapp/newscontroller?action=view&category=money
Returns a news page for the money category
- http://yourhost/yourwebapp/newscontroller?action=update&category=fashion
Allows the 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:
- 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 JavaServer Pages file, the cache entry class is "servlet".
<cache-entry> <name> /newscontroller </name> <class>servlet </class> </cache-entry>
- 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>
- 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>
- 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
You 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
- Dynamic cache service settings
- Configure dynamic cache (DynaCache) to use the WebSphere eXtreme Scale dynamic cache provider
- Configure servlet caching
- Configure portlet fragment caching
- Configure portlet fragment caching with wsadmin.sh
- Configure caching for Struts and Tiles applications
- Configure dynamic cache disk offload
- Configure Edge Side Include caching
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