blogger templates blogger widgets
This is part of a list of blog posts.
To browse the contents go to

cachespec.xml explained

Cache entries are specified in the cachespec.xml file. This is a file that holds cache specification and invalidation policies. It can be placed in the /properties directory for global cache specifications or within WEB-INF directory of each Web module or META-INF of the enterprise bean directory.

cachespec.xml is used for Servlet/JSP caching, Webservice caching and Command caching.

When using the Distributed Object Map, cache is configured programmatically.

<cache> The root element of the cachespec.xml file,
appearing only once. It holds multiple <cache-entry>
<cache-entry> There is one of these for each item to be cached. Cache
entries can describe items to be cached, items which will
invalidate other cache entries, and dependencies between cache
entries. We will see examples of each below.
<class> Identifies the type of entry. Possible values are command,
servlet, and webservice.
<name> The name of the item to be cached. For commands, it should
be the fully qualified package and class name, including the .class
suffix. For servlets or JSPs, it should be the URI path relative to
the application's context root. For example, if the full URL to the
JSP is,
the value here would be /products/catalogList.JSP. If
you were using the cachespec.xml file from the
application server properties directory (global), the entire URL
would be necessary. If you have multiple servlet aliases, multiple
<name> stanzas could be included here to list
each alias that you intend to cache.
<property> Used to set optional properties on a cache entry, such as
whether it can be cached outside of WebSphere Application Server,
and whether this entry can be persisted to disk. (There is a list
of definable properties in the WebSphere Application Server V5
Information Center.) There can be multiple properties per cache
<sharing-policy> Determines whether a cache entry should be shared between
distributed caches, and if so, how that should occur. Distributed
caches will be discussed later.
<cache-id> Where the cache identifiers for each cache entry are
configured. This is a key, similar to a database key structure that
identifies a particular cache entry as unique. Caching is generally
not as simple as specifying a particular servlet, JSP, or command
to cache. These must be qualified with attributes that distinguish
one cache entry from another. For example, caching a servlet that
returns a weather forecast by the URI /weather/forecast
would not be desirable; think of what would happen if one user
asked for the forecast for Miami and that result was cached, and
the following user invoked this URI to get the forecast for
Anchorage. In this case, there is probably a request parameter that
is sent along with the servlet invocation that has the city name or
zip code for the forecast. This is the piece of data that would
ensure the cached results are unique and match the request, so, for
example, Miami forecasts are always returned to other users asking
for Miami weather. This parameter should be designated as required,
as the cache entry is meaningless without it. Sample 5, below,
shows a similar cache specification. There may also be other
parameters as part of the cache ID, such as whether the user is
asking for a short-range or long-range forecast. Each component of
the cache ID is specified in a <component> tag,
as shown in the examples below.

No comments:

Post a Comment