Commerce Composer widget caching and invalidation

Site and store-level widgets can be cached for improved store performance.

Widgets are cached in one of two ways:

Widgets can be cached independently as fragment. This cached fragment is injected into the requested page. This type of caching allows for reuse of the widgets. For example, the header, and footer are cached separately and injected into every page request. These fragments can be invalidated independently without affecting the parent page cache entry.
Widgets can be cached as part of ("consumed" by) the parent page. A requested page can be served fully cached. If widget contents are modified in any way, then the cached page must be invalidated completely.

Note: Widget caching is not enabled by default in WebSphere Commerce Developer. To enable widget caching in WebSphere Commerce Developer, see Enabling Commerce Composer widget caching in WebSphere Commerce Developer.

Every widget has an entry in cachespec.xml. It is within this file where caching parameters are set. Not all widgets are cached, however. Whether a widget is cached, and how it is cached depends primarily on its function:


Widget content	Widget examples	Required cachespec.xml entries	Reasoning
Always dynamic	Inventory Availability widget Discounts widget	The do-not-cache and do-not-consume properties are set to `true`	These widgets are not cached because their content is generated in real-time based on interactions with the shopper. The content is always changing, and is never the same across different shoppers.
Sometimes dynamic	Content Recommendation widget Category Recommendation widget e-Marketing Spot widget	The do-not-cache and do-not-consume properties are set to `true`. The following metaDataGenerator is added: `<metadatagenerator> com.ibm.commerce.marketing.cache.EMarketingSpotMetaDataGenerator </metadatagenerator>`	Marketing widgets can contain static content, or dynamic content that is personalized for different shoppers. Therefore, they can be consumed or cached independently based on their individual behavior. While the do-not-cache and do-not-consume properties are required to be set to `true`, they can be ignored. The included metadata generator decides whether to cache the marketing widgets or not based on if the content is determined to be static or dynamic. For more information, see Overview of e-Marketing Spot JSP caching based on activity behavior.
Static / consumable	Heading widget Short description widget	The do-not-cache and do-not-consume properties are set to `true`. The following special dependency ID is added: `<dependency-id>ignoreDoNotConsume</dependency-id>`	Widgets with static content can be consumed by their parent pages. When a widget is consumed, the widgets dependency IDs must be added to the parent page cache entry. These dependency IDs cause the cached parent page to be invalidated whenever the widget's contents are modified. For this process to be achieved, any consumable widget must contain a special tag within its JSP: `<wcpgl:pageLayoutWidgetCache/>` When the widget JSP executes, the associated tag handler class checks for the presence of the `ignoreDoNotConsume` dependency ID. If present, the do-not-consume attribute is reset to `false`, enabling the widget to be consumed by the parent page. It also adds this widget's dependency ID values to that of the parent page.

Here is a sample cache entry for the static heading widget. Refer to cachespec.xml for more details and examples.

<cache-entry>
	<class>servlet</class>
	<name>/Widgets/com.ibm.commerce.store.widgets.Heading/Heading.jsp</name>
	<property name="save-attributes">false</property>
	<property name="consume-subfragments">true</property>
	<property name="do-not-consume">true</property> <!--  will be reset to false, since ignoreDoNotConsume dependency-id is present -->
	<property name="do-not-cache">true</property> 
	<cache-id>
		<component id="langId" type="parameter">
			<required>true</required>
		</component>
	</cache-id>
	
	<dependency-id>categoryId
		<component id="categoryId" type="parameter">
			<required>true</required>
		</component>
	</dependency-id>
	
	<dependency-id>productId
		<component id="productId" type="parameter">
			<required>true</required>
		</component>
	</dependency-id>
	
	<dependency-id>ignoreDoNotConsume</dependency-id>
	
</cache-entry>