Full page and fragment caching

The method by which the WebSphere Application Server dynamic cache caches JSP files is based on how the JSP is written. If the page output for a particular WebSphere Commerce command always produces the same result based on the URL parameters and request attributes, then this page output can be cached with the cache-entry using the property element, consume-subfragments (CSF) along with the WebSphere Commerce controller servlet (com.ibm.commerce.server.RequestServlet) as the servlet name. When the cache-entry is defined in this manner, then the page output is cached in a manner known as full page caching. The big advantage of using consume-subfragments with the controller servlet is performance, but if this mechanism is used to cache the web pages, then the page output can not have personalized information on it.

If the page output has sections that is user-dependent, then the page output is cached in a manner known as fragment caching. That is, the JSP pages are cached as separate cache entries, and get reassembled when they are requested. For fragment (JSP) caching, WebSphere Commerce has to execute the command to determine which JSP is to be executed before the dynamic caching mechanism can determine if the JSP can be served up from cache or not. The advantage of this method is flexibility, because different cache entries can be reassembled together to form a page, based on user information.

Full page caching

When the property element consume-subfragments (CSF) is used, the parent entry (the one marked with CSF) will include all the content from all fragments in its cache entry, resulting in one big cache entry that has no includes or forwards, but rather, the content from the whole tree of entries.

When a servlet is cached, only the content of that servlet is stored. The cache includes place holders for any other fragments to which it includes or forwards. Consume-subfragments (CSF) tells the cache not to stop saving content when it includes a child servlet. The parent entry (the one marked CSF) will include all the content from all fragments in its cache entry, resulting in one big cache entry that has no includes or forwards, but the content from the whole tree of entries. This can save a significant amount of application server processing, but is typically only useful when the external HTTP request contains all the information needed to determine the entire tree of included fragments.

For example, if the <cache-entry> is defined as follows:

<cache-entry>
  <class>servlet</class>
  <name>com.ibm.commerce.server.RequestServlet.class</name>
  <property name="consume-subfragments">true</property>
  <property name="save-attributes">false</property>
  <property name="store-cookies">false</property>

  <!-- StoreCatalogDisplay?storeId=<storeId> -->
  <cache-id>
     <component id="" type="pathinfo">
        <required>true</required>
           <value>/StoreCatalogDisplay</value>
     </component>
     <component id="storeId" type="parameter">
        <required>true</required>
     </component>
  </cache-id>
</cache-entry>

Note that when the save-attributes property is set to false, the request attributes are not saved with the cache entry. When the store-cookies property is set to false, the request cookies are not saved with the cache entry.

In the above example, the cache servlet entry will contain a consumed include of StoreCatalogDisplay.jsp which is the JSP file forwarded by the StoreCatalogDisplay command.

Fragment cache

Each dynamically included JSP file has to have its own <cache-entry> defined in the cachespec.xml file in order to be served up by the dynamic cache when it receives a request. Otherwise, each dynamically included JSP file will be re-executed for each request. For example, consider if StoreCatalogDisplay.jsp dynamically includes CachedHeaderDisplay.jsp, CachedFooterDisplay.jsp and CachedStoreCatalogDisplay.jsp and you only set up a <cache-entry> for the CachedStoreCatalogDisplay.jsp. Then, when you request the StoreCatalogDisplay page, the CachedStoreCatalogDisplay.jsp, CachedHeaderDisplay.jsp and CachedFooterDisplay.jsp files will get executed if they are not cached. Here is an example of how to define the <cache-entry> for CachedStoreCatalogDisplay.jsp:

<cache-entry>
  <class>servlet</class>
  <name>/AdvancedB2BDirect/ShoppingArea/CatalogSection/CategorySubsection/CachedStoreCatalogDisplay.jsp</name>
  <property name="save-attributes">false</property>
  
  <cache-id>
     <component id="storeId" type="parameter">
          <required>true</required>
     </component>
     <component id="catalogId" type="parameter">
          <required>false</required>
     </component>   
  </cache-id>
</cache-entry>

Feedback