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> stanzas.
<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 http://www.myco.com/myapp/products/catalogList.JSP, 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 entry.
<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.