Caches content that changes infrequently.

Class Name




Required Input Parameters


Lets you have more than one view of content based on a value that uniquely defines the view of the content. For example, if content is displayed one way for members and another for non-members, you can pass in the value of the member trait as the key parameter.

Optional Input Parameters


Determines how cached URLs are rendered for future requests. By setting hasNoURLs to false, you specify that subsequent requests for the cached content causes URLs to be rewritten on the fly, assuming URL Rewriting is enabled. A setting of false for hasNoURLs causes URLs to be saved and rendered exactly as they are currently (without session or request IDs) regardless of whether URL rewriting is enabled.


The interval after content is cached until the cached is regenerated. If omitted, the interval is set from the defaultCacheCheckSeconds property in the Cache servlet bean’s properties file.

Open Parameters


The code enclosed by the output open parameter is cached.

Usage Notes

Cache can help reduce repetitive time-consuming tasks by keeping content in temporary memory. When you use Cache, you specify the content to cache and how frequently to clear the cache. Cached URLs do not retain session or request IDs.

Which content to cache

Caching data resolves many tasks into one. Consider a Switch servlet bean that returns one set of RepositoryItems to females and another set to males. Each time that code is executed two time-consuming tasks occur: the Switch servlet bean is processed and the outcome repositoryItem is retrieved. Embedding the Switch servlet bean in Cache causes the following to occur in future executions: DAF queries only the gender property of the Profile component (which is stored locally) and provides the appropriate content (also stored locally).

The following example is an ideal candidate for use with the Cache servlet bean because it is involves expensive operations—page computations and querying the database.

In determining whether the Cache servlet bean is appropriate for a given situation, consider the following:

  • When retrieving data from the data base, is the retrieved data rendered for many users? Cache can limit the number of times the database is queried. Any code in which the database is not queried should not be cached.

    That said, caching might not be appropriate for all data retrieved from the database, especially when the data is accessed through a personalization servlet bean , such as retrieving images for all items purchased by a particular user. It is likely that these items are different for most users so the cached data is not reused.

  • When processing JSP code, is the output useful for many users? Actions that are personalized to users, such as displaying a user name or a URL that includes a session ID, are an inefficient use of resources because they require processing to incorporate the dynamic elements, processing that occurs each time the cached code is rendered. Code that invokes personalized results is not a suitable candidate for the Cache servlet bean.

  • Does using Cache conserve more resources than it expends? Caching a string is wasteful because it takes more time to cache it than to render it many times.

In summary, use Cache to hold content that is expensive to compute, so the data to cache takes longer to process on its own than it takes to render Cache and resolve its key parameter for that data. A common example is code that renders content from the database for a large subset of your user community. Although you might want Cache to involve some personalization (determining that subset), if you also want to cache programming code, make sure the output is saved by Cache. Avoid Cache in these circumstances:

  1. When the content to cache is static.

  2. When it takes more time to cache the content than to render the content.

  3. When the cached content is not applicable for many users.

It is a good idea to measure your page performance with and without Cache as the final determination of its efficiency for a given circumstance.

Clearing the cache

You can determine how often data is flushed for a given Cache instance on a JSP or for all instances of Cache. To remove cached content associated with a particular instance of Cache, set the cacheCheckSession input parameter in the Cache instance to the frequency by which associated data should be expired. If you omit this parameter, the Cache.defaultCacheCheckSeconds property is used (default value is 60 seconds) .

The Cache.purgeCacheSeconds property determines how often content cached by any Cache servlet bean is flushed. The default is 21600 seconds (6 hours). Cache purging also occurs when a JSP is removed or recompiled.


The following example demonstrates a simple implementation of Cache that displays gender-specific articles to users. The fictitious GenderSpecificArticles servlet bean determines the current user’s gender and displays one set of articles to men and a different set to women.

The following JSP code renders gender-specific content:

<dsp:droplet name="GenderSpecificArticles">

Content for women looks like this:

<a href="womensarticle1.html">women's article 1</a>
<a href="womensarticle2.html">women's article 2</a>

Content for men looks like this:

<a href="mensarticle1.html">men's article 1</a>
<a href="mensarticle2.html">men's article 2</a>

The following example caches the preceding code:

<dsp:droplet name="/atg/dynamo/droplet/Cache">
  <dsp:param bean="Profile.gender" name="key"/>
  <dsp:oparam name="output">
    <dsp:droplet name="GenderSpecificArticles">

The Cache servlet bean defines male and female as cache keys. The male key is set to the following string:

"<a href="mensarticle1.html">men's article 1</a>
<a href="mensarticle2.html">men's article 2</a>"

The female key is set to the following string:

"<a href="womensarticle1.html">women's article 1</a>
<a href="womensarticle2.html">women's article 2</a>"

The first time the JSP holding the Cache servlet bean is rendered, the GenderSpecificArticles servlet bean executes, but future requests for this page simply look up the result of GenderSpecificArticles in the cache and display the appropriate string.

loading table of contents...