This section of the tutorial is designed to illustrate through examples, the steps involved in defining a cache policy. By the end of this section you will be able to:
- Publish your store or store archive
- Define the cache policy
Publishing your store or store archive
After you have successfully created a WebSphere Commerce instance, you can publish a starter store. To follow steps to publish a starter store, see Publishing a store archive. In this case, select the Advanced B2B Direct store for publishing.
Defining the cache policy
After you have published the starter store, you can begin to define your cache policy. In order for dynamic cache to cache servlets and JSP page results, the cache-entry element has to be defined in the cache policy configuration file (cachespec.xml).
For caching servlet and JSP page results, you must do the following:
- Define the class element as servlet
- Define the name element. This element must include either the full URI of the JSP page, of the fully classified name of the servlet.
For example:
<name>com.ibm.commerce.server.RequestServlet.class</name> <name>/ToolTech/ShoppingArea/CatalogSection/CategorySubsection/StoreCatalogDisplay.jsp</name>
Note: WebSphere Commerce has only one controller servlet for the Stores.war named com.ibm.commerce.server.RequestServlet.class. Therefore, when caching with the servlet class, a filtering mechanism is needed to determine what needs to be cached. This can be accomplished by using the attribute type pathinfo in the component sub-element in the cache-id specification. For example:
<component id="" type="pathinfo"> <required>true</required> <value>/StoreCatalogDisplay</value> </component>
For more details on defining cache policy using the cachespec.xml file, see Configuring cacheable objects.
Caching full pages
If the web page you have selected can be cached as a whole page, the cache-entry element will have to be specified for that intention. See Full page and fragment caching for examples of that specification. Copy and paste the code samples from that page into your cachespec.xml file.
Caching page fragments
See Full page and fragment caching for examples of caching page fragments. Copy and paste the code samples from that page into your cachespec.xml file.
Defining cache IDs
Each cache-id element defines a rule for caching an object and is composed of the following sub-elements:
- component
- time-out
- priority
- property
- Copy and paste the following into your cachespec.xml file.
<cache-entry> <class>servlet</class> <name>/AdvancedB2BDirect/ShoppingArea/CatalogSection/CategorySubsection/CachedStoreCatalogDisplay.jsp</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> <component id="catalogId" type="parameter"> <required>true</required> </component> <component id="DC_lang" type="attribute"> <required>true</required> </component> </cache-id> </cache-entry
- Then, for the above example invoke the following URL: https://hostname/webapp/wcs/stores/servlet/StoreCatalogDisplay?langId=-1&storeId=10051&catalogId=10101.
- Access the cache monitor at the following URL: http://hostname:8002/cachemonitor. You should then see the following cache ID: /webapp/wcs/stores/servlet:pathinfo=/StoreCatalogDisplay:storeId=10051:catalogId=10101:DC_lang=-1:ISO8859-1.
As you can see, each component defined, becomes part of the cache ID that is generated.
Note: The values of -1, 10051, 10101 used for langId, storeId and catalogId shown in the above steps may be different in your case, depending on your system.
Defining dependency IDs
A dependency ID is also known as grouping ID because it can be used to group multiple cache entries with the same group identifier. Dependency ID rules should be defined with cache invalidation in mind so that when a product is updated for a particular store, catalog, etc., the cache entries can be invalidated as a bundle.
For example:
<cache-entry> <class>servlet</class> <name>/ToolTech/ShoppingArea/CatalogSection/CategorySubsection/StoreCatalogDisplay.jsp</name> <property name="save-attributes">false</property>
<cache-id> . . . </cache-id> <dependency-id>storeId <component id="storeId" type="parameter"> <required>true</required> </component> </dependency-id> <dependency-id>catalogId <component id="catalogId" type="parameter"> <required>true</required> </component> </dependency-id> </cache-entry>
For the above example if the URL
http://hostname/webapp/wcs/stores/servlet/StoreCatalogDisplay?langId=-1&storeId=10001&catalogId=10001 is invoked, the dependency IDs generated are:
- storeId:10001
- catalogId:10001
Considering store relationships
If you are caching Web pages that involve resources shared, then you might have to set up your dependency IDs differently to define the resources relationship in order to support cache invalidation. See the "Implementing caching for store pages that use store relationships", and the Store relationship caching example", sections in Creating store pages that can be cached.
Summary
This section of the tutorial showed you the steps involved in defining a cache policy. You should now be able to:
- Publish your store or store archive
- Define the cache policy