InfoCenter Home >
4: Developing applications >
4.5: Dynamic fragment cache >
4.5.1: Custom ID and MetaData generators
4.5.1: Custom ID and MetaData generators
WebSphere Application Server's dynamic cache technology allows users to replace
the standard configuration functions with their own custom configuration classes.
The configuration duties managed by cache fall into two categories:
- Generating cache and group ids
- Defining meta data such as timeout, priority, and external caching
Application developers can supply classes to handle either or both of these sets of
responsibilities, by implementing com.ibm.websphere.servlet.cache.IdGenerator and
com.ibm.websphere.servlet.cache.MetaDataGenerator.
Overriding the default MetaDataGenerator allows users to access configuration information from some other source.
or makes timeout, priority, or external cache group a function of a variable rather than a constant.
A new IdGenerator gives users the ability to determine cache entry ids and their group ids.
Both classes can still use the cache policy attributes defined for a servlet (<timeout>, <priority>, <request>, and others)
to relay data to their generators using the com.ibm.websphere.servlet.cache.CacheConfig class.
Each servlet class has individual IdGenerator and MetaDataGenerator objects associated with it.
So if the same servlet is being executed by WebSphere Application Server in different threads,
all threads will use the same pair of generator objects.
Several dynamic caching classes are not described in detail in this article.
See the com.ibm.websphere.servlet.cache package (Javadoc) for more inforamtion
on the classes and interfaces used by the cache function.
Custom Id generators
- Configuring the cache to use a custom IdGenerator:
To specify your IdGenerator in the XML file, use the <idgenerator> tag.
<servlet>
<timeout seconds="0"/>
<path uri="/servlet/CommandProcessor" />
<idgenerator class="SampleIdGeneratorImpl" />
</servlet>
You can also use the Application Assembly Tool to define the IdGenerator class in the cache policy's Advanced tab.
- Building a custom IdGenerator:
Your IdGenerator must implement the com.ibm.websphere.servlet.cache.IdGenerator interface.
There are three methods in the IdGenerator interface:
- public void initialize(CacheConfig cc);
- public String getId(ServletCacheRequest request);
- public int getSharingPolicy(ServletCacheRequest request);
The getSharingPolicy method should return EntryInfo.NOT_SHARED
The initialize method is called during startup.
Normally, the cache processes a servlet's XML configuration and builds a CacheConfig
object that is made available to the IdGenerator. The initialize method then builds
a list of request and session variables that must be included in the cache ids
for the servlet. Since the "plugged-in" IdGenerator is created with a specific
servlet's behavior in mind, working with the CacheConfig is unnecessary;
just hard code the configuration into the getId method.
The getId method returns the unique String cache id
when the servlet is invoked. If the servlet is cached, the getId
method returns null. Typically, an Id will incorporate the following:
- The URI of the servlet
- The character encoding of the request (when the result is not null)
- The names and values of the input variables that determine the servlet's output
See the coding example for implementation details.
|
|