Servlets and JSP caching in Websphere

The servlet/JSP caching facility will catch the response from servlet/JSP invocation and cache the HTML results. Servlets are configured for caching via entries in the cachespec.xml file (described here). They can be designated by their URI path, or by classname. The latter option is more inclusive, since it will catch any invocation of the servlet regardless of the aliases. In most cases, the cache entry for the servlet needs to be further qualified by additional inputs, such as the request parameters or values from the user session information. We will explain this further in our section on specifying cache entries.

When preparing to execute a servlet, the dynacache engine filters the service() method of each servlet that is about to be executed, and determines if this matches any cache ID entries based on the parameters present. If a match is found, the cached results are returned rather than executing the service() method and all of the work that would have been done beyond it. This avoids all of the processing that would have been done by the servlet, resulting in a substantial performance boost. If there is not a cache entry for this ID, the service() method is executed as normal and the results are caught and placed in the cache before they are returned to the user.


Sample cachespec.xml file for a JSP

<cache>
   <cache-entry>
      <class>servlet</class>              
      <name>/displayForecast.jsp</name>
      <property name="EdgeCacheable">true</property>
      <cache-id>
         <component id="zip" type="parameter">
            <required>true</required>
         </component>
         <priority>3</priority>
         <timeout>20</timeout>
      </cache-id>
   </cache-entry>
</cache>

Above is a simple cachespec.xml file with a single cache entry for a JSP. You might notice that the class is servlet, while the name clearly identifies a JSP. This is because JSPs are compiled into servlets on the backend, so from the application server's perspective, they are essentially the same thing. This JSP has a property that states that it is "edge cacheable".

Notice that the cache ID is composed of a single request parameter, the zip code for the forecast. This means that if seven users request forecasts for seven different zip codes, there will be seven cache entries in the cache with the zip code serving as their key. Subsequent users requesting forecasts for any of these seven zip codes will be served up the forecast for the appropriate area. This cache entry has been configured with a priority of 3, meaning it gets three "free passes" if it is designated as ready to be invalidated by the LRU algorithm, mentioned earlier in our discussion on invalidation. The entry is set to a default timeout of 20 seconds; however, it could be invalidated earlier by means of a program API, another cache entry that is designated to invalidate it, or purging due to a full cache.