Caching Servlet Results

The Application Server can
cache the results of invoking a servlet, a JSP, or any URL pattern to make
subsequent invocations of the same servlet, JSP, or URL pattern faster. The Application Server caches
the request results for a specific amount of time. In this way, if another
data call occurs, the Application Server can return the cached data instead of
performing the operation again. For example, if your servlet returns a stock
quote that updates every 5 minutes, you set the cache to expire after 300
seconds.

Whether to cache results and how to cache them depends on the data involved.
For example, it makes no sense to cache the results of a quiz submission,
because the input to the servlet is different each time. However, it makes
sense to cache a high level report showing demographic data taken from quiz
results that is updated once an hour.

To define how an Application Server web application handles response caching,
you edit specific fields in the sun-web.xml file.

Note –

A servlet that uses caching is not portable.

A sample caching application is in install-dir/samples/webapps/apps/caching.

Caching Features

The Application Server has the following web application response caching
capabilities:

Caching is configurable based on the servlet name or the URI.

When caching is based on the URI, this includes user specified
parameters in the query string. For example, a response from /garden/catalog?category=roses is different from a response from /garden/catalog?category=lilies. These responses are stored under different keys in the cache.

Cache size, entry timeout, and other caching behaviors are
configurable.

Entry timeout is measured from the time an entry is created
or refreshed. To override this timeout for an individual cache mapping, specify
the cache-mapping subelement timeout.

To determine caching criteria programmatically, write a class that implements the com.sun.appserv.web.cache.CacheHelper interface. For example, if only a servlet knows when a back end
data source was last modified, you can write a helper class to retrieve the
last modified timestamp from the data source and decide whether to cache the
response based on that timestamp.

All non-ASCII request parameter values specified in cache
key elements must be URL encoded. The caching subsystem attempts to match
the raw parameter values in the request query string.

Since newly updated classes impact what gets cached, the web
container clears the cache during dynamic deployment or reloading of classes.

The following HttpServletRequest request attributes are exposed:

com.sun.appserv.web.cachedServletName,
the cached servlet target

com.sun.appserv.web.cachedURLPattern, the
URL pattern being cached

Results produced by resources that are the target of a RequestDispatcher.include() or RequestDispatcher.forward() call are cached
if caching has been enabled for those resources. For details, see the descriptions
of the cache-mapping and dispatcher elements in the sun-web.xml file.

Default Cache Configuration

If you enable caching but do not provide any special
configuration for a servlet or JSP, the default cache configuration is as
follows:

The default cache timeout is 30 seconds.

Only the HTTP GET method is eligible for caching.

HTTP requests with cookies or sessions automatically disable
caching.

No special consideration is given to Pragma:, Cache-control:, or Vary: headers.

The default key consists of the Servlet Path (minus pathInfo and the query string).

A “least recently used” list is maintained to
evict cache entries if the maximum cache size is exceeded.

Key generation concatenates the servlet path with key field
values, if any are specified.

Results produced by resources that are the target of a RequestDispatcher.include() or RequestDispatcher.forward() call are never
cached.

For more information about the sun-web.xml caching
settings, see cache.

CacheKeyGenerator Interface

The built-in default CacheHelper implementation
allows web applications to customize the key generation. An application component
(in a servlet or JSP) can set up a custom CacheKeyGenerator implementation
as an attribute in the ServletContext.

The name of the context attribute is configurable as the value of
the cacheKeyGeneratorAttrName property in the default-helper element
of the sun-web.xml deployment descriptor. For more information,
see default-helper.