2.7.5 DynaCache fragment caching
In DynaCache, fragment caching generally means caching a part of a rendered HTML page. In practice, a page may not be "cacheable" in its entirety, but it may contain sections of varying cacheability that can be separated into fragments and cached independently. Any content that can be independently requested can make up a cacheable fragment.
For fragment (JSP) caching, WebSphere Commerce has to execute the command (controller, task, and view commands) to identify which JSP is to be executed before DynaCache can determine whether the JSP can be served from the cache or not. The advantage of this method is flexibility, because different cache entries could be reassembled to form a page based on user information.
In order for a fragment to be cacheable, the fragment has to be executable on its own. That is, it must be able to execute independently of any other fragments of the Web page. Because the fragment being excluded must be self-executing, it cannot depend on any attributes set by the parent JSP fragment - unless an attribute has been defined as being cached with the parent.
This can be a problematic because not all fragments in WebSphere Commerce are self-executing. To test if the fragment is self-executing, pass the fragment's URL to a Web browser, including the necessary parameters. For example, the mini shopping cart contained in the ConsumerDirect sample store is accessed by the following URL:
http://localhost/webapp/wcs/stores/servlet/ConsumerDirect/include/MiniShopCartDisplay.jsp?storedId=10001.
The following method describes an alternative way of determining if the fragment is self-executing. After the cachespec.xml file is configured, click the servlet's page.
- Use the cache monitor to invalidate the child fragment.
- Execute the page request to confirm the execution of the fragment is successful.
If the execution is successful, that fragment is self-executing.
Figure 2-17 Each of these three eMarketing Spots is self-executing and can therefore be cached individually
You could cache the eMarketing spot by using the cache entry shown below...
Example 2-12 Caching the eMarketing spot.
<class>servlet</class>
<name>/ConsumerDirect/include/eMarketingSpotDisplay.jsp</name>
<property name="store-cookies">false</property>
<property name="save-attributes">false</property>
<property name="do-not-consume">true</property>
<cache-id>
<component id="emsName" type="parameter">
<required>true</required>
</component>
<component id="maxNumDisp" type="parameter">
<required>true</required>
</component>
<component id="catalogId" type="parameter">
<required>true</required>
</component>
<component id="maxItemsInRow" type="parameter">
<required>true</required>
</component>
<component id="maxColInRow" type="parameter">
<required>true</required>
</component>
<priority>1</priority>
<timeout>3600</timeout>
</cache-id>
The cache-entry for the parent servlet contains values for those parameters passed into the fragment using the jsp:include or c:import tags. This means that on a cache hit, the parameters passed from the parent to the fragment are not regenerated. To have new values passed to the fragment, invalidate or re-execute the parent JSP