Websphere Commerce’s Caching mechanism.

Continuation of Websphere Commerce Questions and Answers I.

Q12:Explain the Dynacache?(I talked about it so much, so it became a very lengthy answer , had to write it a separate blog post for it,even though in blog post put just what a little bit I remember but that ‘little bit’ too is quite much  🙂  )
Ans:Caching should be implemented for the content that changes frequently or is stable for a period of time or  contains a majority of contents that can be reused by a variety of users
Dynamic Cache aka DynaCache is provided by IBM Websphere Application server to be configured to store some objects and later based on some matching rules Dyna cache retrieve those objects from the cache.
Caching rules are specified in Cachespec.xml file present in the Stores.war.
Caching improves response time and reduces system load to improve the performance of world-wide web applications.
Dyna caching service, places the objects in the cache which is identified by unique cache-id’s (<cache-id> rules) defined in the <cache-entry> elements.
Once the objects with particular cache-id are in the cache, then the subsequent request for the same cache-id is served from the cache.
Cached objects are removed from the cache according to the information provided in the <cache-entry> elements such as <time-out>, <invalidation> and <priority> elements.

The Dyna caching service includes:-

  1. Servlet or JSP result cache(caching the fragments of JSP or whole page).
  2. Cache business objects.
  3. Edge Side Include (ESI) caching to cache, assemble and deliver the dynamic web pages at the edge of enterprise network.
  4. Invalidation support to ensure that the content of cache is correct. Invalidation can be rule-based, time-based, group-based and programmatic.
  5. Replication support, to enable cache sharing and replication on multiple servers.
  6. Disk offload capability, to enable and storing large amount of data, preserve the content in the application server until it is restarted or stopped.

When the available cache memory is full, LRU algorithm removes the cached objects with the lower priority.
The <dependency-id> and <invalidation> elements defines the rule to generate dependency-id’s and the invalidation-id’s, which together specify certain objects should be removed from the cache after the request is processed.
The <inactivity> element is used to specify a time to live (TTL) value for the cache entry based on the last time that the cache entry was accessed.

CACHEIVL table records the changes to product or category information in the database. This is referred by WCS for invalidating dynacache.

We can see , monitor and can even change dynacache manually but for that we need to install a seperate application provided by WCS(will be explained in other blog post).

Things to consider when implementing caching for WebSphere Commerce,

  1. Which pages should be cached
  2. Where caching should take place
  3. Need to cache full pages or page fragments
  4. How to invalidate the cached data.

Following is an example of <cache-entry> uses a <cache-id> element to cache results created by a JSP and generate a cache ID with four components, “storeId”,”langId”,”omitHeader” and “catalogId”, obtained from parameters in the request object:

<cache-entry>
<class>servlet</class>
<name>/MyAssetStore/Widgets/Banner.jsp</name>
<property name=”do-not-consume”>true</property> <!– Do not consume with parent –>
<property name=”do-not-cache”>false</property> <!– Cache it –>
<property name=”save-attributes”>false</property>
<property name=”consume-subfragments”>true</property>
<property name=”ignore-get-post”>true</property>
<sharing-policy>not-shared</sharing-policy>

<cache-id>
<component id=”storeId” type=”parameter”>
<required>true</required>
</component>
<component id=”langId” type=”parameter”>
<required>true</required>
</component>
<component id=”catalogId” type=”parameter”>
<required>true</required>
</component>
<component id=”omitHeader” type=”parameter”>
<required>false</required>
</component>
</cache-id>
……….
</cache-entry>

How Not to cache the page?

  1. Not caching the whole page:

    <%@ page import = “com.ibm.commerce.webcontroller. HttpControllerRequestObject” %>
    <%@ page import=”javax.servlet.http.HttpServletRequest” %>
    <%@ page import=”com.ibm.commerce.server.JSPHelper” %>
    <%@ page import=”com.ibm.commerce.command.CommandContext” %>

    <%

    CommandContext commandContext = (CommandContext)request. getAttribute(“CommandContext”);         HttpControllerRequestObject controllerReq = (HttpControllerRequestObject)commandContext.getRequest();
    HttpServletRequest req = controllerReq.getHttpRequest();
    JSPHelper.setUncacheable(req,true);

    %>

  2. Not caching the fragment of page:

    <%@ page import=”com.ibm.websphere.servlet.cache.*” %>
    <% 

     ((ServletCacheResponse)response).setDoNotConsume(true);

    %>

How to Invalid Cache?
Ans:  Following are the methods can be used for cache invalidation

  1. Invalidating the cache using timeout: This can be done by adding <timeout>10</timeout> inside of <cache-id> element. The timeout value will be in seconds. If the default value is 0, then the cache will not expire.something like

    <cache-id>
    <component id=”catalogId” type=”parameter”>
    <required>true</required>
    </component>
    <component id=”storeId” type=”parameter”>
    <required>true</required>
    </component>
    <timeout>86400</timeout>
    </cache-id>

  2. Using Command invalidation: Command based invalidation means invalidation rules are executed upon the execution of the command that extends CachableCommandImpl WebSphere Command framework.The invalidation id’s are constructed based on the fields and methods provided by command.
  3. Invalidating cache using dyna cache API and CACHEIVL table: WebSphere provides DynaCacheInvalidation command which is called by scheduler to process the record in CACHEIVL table(referenced above).
  4. Invalidating cache using dependency trees: Cache can be invalidated by using dependency ids .For Instance.<dependency-id>Apparel<component id=”” ignore-value=”true” type=”pathinfo”><required>true</required><value>/CategoryDisplay</value></component><component id=”parent_category_rn” ignore-value=”true”  type=”parameter”><required>true</required><value>10003</value></component>

    </dependency-id>

Limitations of dynamic caching

If you use the cachespec.xml file to enable invalidation you might encounter the following behavior:

  • When you create a catalog entry or move a catalog entry from one category to another in the Management Center, the catalog entry would not show up on the storefront.
  • When you create a category in the Management Center, the category would not show up on the storefront.
  • When you update a child object in the Management Center, the parent object cache entry is not automatically invalidated. For example, when you update a catalog entry in the Management Center, the category display page does not reflect the updates in the storefront.

To resolve these problems, invalidate cache manually.

How can we remove a JSP page from getting cached ?
Ans. Remove the jsp entry from cachespec.xml.

 

What is reload interval and where it is defined ?
Ans. reload interval or jsp caching interval is a parameter that indicates how frequently a JSP should be recompiled.
It is defined within
Stores.war\WEB-INF\ibm-web-ext.xml

 

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s