Caches content that changes infrequently.
Class Name |
|
---|---|
Component |
|
Required Input Parameters
key
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
hasNoURLs
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.
cacheCheckSeconds
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
output
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 Repository
Items
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 repository
Item
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:
When the content to cache is static.
When it takes more time to cache the content than to render the content.
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.
Example
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"> </dsp:droplet>
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"> </dsp:droplet> </dsp:oparam> </dsp:droplet>
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.