Commerce Composer layout caching and invalidation

The page display JSP is the main JSP in the Commerce Composer solution, and is mapped to a view in struts-config-ext.xml. It is responsible for retrieving layout details for each page request from the Commerce Composer framework. The store front contains page display JSPs for individual page types, such as category, product, and content pages. In select instances, retrieved layouts can be cached for increased store performance.

A page display JSP makes a request to the commerce composer framework to identify and render a winning layout that is based on the passed objectId and pageGroup type. A couple of examples are as follows:

productId = 10001, pageGroup = Product
categoryId = 10002, pageGroup = Category

The resulting layout can be cached automatically if com.ibm.commerce.pagelayout.cache.PageDesignMetaDataGenerator determines that the winning layout is the same for all customers. The layout activity is evaluated by the marketing activity framework, and if it is determined to be static, the layout can be cached.

Depending on whether the individual layout is cached, PageDesignMetaDataGenerator modifies the page display JSP's entry in the cachespec.xml configuration file.

If the page is not to be cached, the do-not-cache property is set to true.

If the page is to be cached, the do-not-cache property is set to false. In addition, PageDesignMetaDataGenerator adds the required dependency IDs to the cache entry. These dependency IDs aid in the invalidation of the cached layout when the layout is switched, or if the layout is modified.


Dependency ID	Description
`emsName:name`	Each layout marketing e-Spot is evaluated by the marketing activity framework to determine the layout, and is added as a dependency. If a different layout is associated with this objectId and pageGroup, then this dependency ID triggers a cache invalidation.
`pageLayoutId:layoutId`	A single dependency ID is generated from a tag within the layout JSP. Each layout must include this tag within its JSP in the following format: `<wcpgl:pageLayoutCache pageLayoutId="${pageDesign.layoutID}"/>` If the associated layout itself is modified by the business user, then this dependency ID triggers a cache invalidation.

If the layout is not cached, its contents can still be cached independently as fragments. See widget caching and invalidation for further details.

Here is a sample cache entry for the ProductDisplay layout. Refer to cachespec.xml configuration file for more details and examples.

<cache-entry>
		<class>servlet</class>
		<name>com.ibm.commerce.struts.ECActionServlet.class</name>

<!-- Displays catentry details using either ProductDisplay.jsp or BundleDisplay.jsp or PackageDisplay.jsp 
The purpose of ProductDisplay command is to retrieve the configured display Page for the specified Product/Bundle/Package/Item in in the specified catalog. 
That display page will in turn be launched to display the catentry information. It looks at DISPENTREL table to get the JSP pages to display the product. -->

	<cache-id>
			<component id="" type="pathinfo">
				<required>true</required>
				<value>/ProductDisplay</value>
			</component>
			<component id="storeId" type="parameter">
				<required>true</required>
			</component>
			……
			……
			<component id="productId" type="parameter"> 
				<required>true</required>
			</component>
			<component id="categoryId" type="parameter">
				<required>false</required>
			</component>
			<metadatagenerator>com.ibm.commerce.pagelayout.cache.PageDesignMetaDataGenerator</metadatagenerator>
		</cache-id>