Home
Property do-not-cache
Use this property when you want DynaCache to totally ignore the fragment. This means that DynaCache will neither cache nor consume the fragment, meaning no part of that fragment will come from the cache and the fragment must be processed by the application server runtime.
<cache-entry> <class>servlet</class> <name>/AChildOfParentMainPage.jsp</name> <property name="do-not-cache">true</property> <cache-id> <timeout>0</timeout> </cache-id> </cache-entry> <cache-entry> <class>servlet</class> <name>/ParentMainPage.jsp</name> <property name="consume-subfragments">true</property> <cache-id> <timeout>0</timeout> </cache-id> </cache-entry>Even though ParentMainPag.jsp is consuming subfragments and includes AChildOfParentMainPage, AChildOfParentMainPage.jsp will not be cached or consumed.
Do-not-cache can also be extended for use in edge side includes and therefore cached on the edge of your network.
<cache-entry> <class>servlet</class> <name>/DoNotCache.jsp</name> <property name="do-not-cache">true</property> <property name="edge-cacheable">true</property> <cache-id> <timeout>0</timeout> </cache-id> </cache-entry>Notice the presence of the edge-cacheable property in Example | -2. This property and the "do-not-cache" property must be present to define a fragment that is not cacheable on the edge.
When to use do-not-cache
A fragment must be self-executing to be cacheable; however, not every self-executing fragment is cacheable. Instead of rendering this entire page uncacheable, you can elect to cache the full page and leave some fragments uncached.
There are very few fragments that are not cacheable. Before designating something as not cacheable, determine the value of caching the fragment versus the possible changes required to make the fragment cacheable. We recommend that you use this technique infrequently.
Before you decide a fragment is uncacheable, consult the different invalidation techniques available for cache content.
do-not-cache anti-pattern
We have seen cases where the do-not-cache property has been incorrectly used to compensate for poor page design. For example, don't use do-not-cache to bypass rarely used page fragments like personalized e-mail address details. If ninety-five percent of your clients don't use that e-mail fragment then it should really have been placed on a separate page and a link inserted in its place.
A poor design forces everyone to have to absorb the performance costs of generating that e-mail detail for the sake of the few who actually will use it. If the site is a high volume Web site with many hundreds of thousands of hits per hour, we will hit the database for every singe page request in order to provide that e-mail address, even though the vast majority of the users don't want it. Attention to small details like that can make big performance differences.