Prior to WebSphere Commerce Version 5.5, WebSphere Commerce provided its own caching mechanism. Using the previous mechanism, Web pages could be cached based on two types of methods:
- Session independent (SI) caching - Pages were cached based on URL parameters
- Session dependent (SD) caching - Pages were cached based on URL parameters, user's language, preferred currency, parent organization, contract Ids, and member groups
Cache IDs for SI caching were generated based on the URL parameters, and for SD caching, the cache IDs were created with the URL parameters plus the session information.
In order to provide the same functionality as the previous session dependent caching but using the WebSphere Application Server dynamic caching mechanism, WebSphere Commerce has introduced a servlet filter known as the cache filter. This cache filter is designed to setup the request attributes from the session information to be used by the dynamic cache to construct the cache ID. Since the session information is set by the WebSphere Commerce Server runtime, the cache filter will not be able to set all of the request attributes until the second request against the Web site.
The following table lists the request attributes that are set by the cache filter:
Request attributes | Description |
---|---|
DC_curr | User's preferred currency |
DC_lang | User's preferred language |
DC_porg | User's parent organization |
DC_cont | User's current contract |
DC_mg | User's explicit member groups |
DC_storeId | Store identifier |
DC_userId | User's identifier |
DC_portal | WebShere Portal's adapter identifier |
DC_buyCont | Buyer's eligible contracts (only valid for Supply Chain business model) |
Since a user can be eligible for multiple contracts and can belong to multiple member groups, the request attributes DC_cont and DC_mg might contain multiple values. For such a user, the values are sorted and concatenated together with a semicolon(";") as a separator. In addition, multiple contract and member group request attributes will be defined. (for example, DC_cont0, DC_cont1, ... DC_contN where N is the number of contracts to which the user is entitled). For example, if a user is eligible for contracts 10004 and 10005, then the following request attributes will be set up: DC_cont is 10004;10005, DC_cont0 is 10004, DC_cont1 is 10005.
The purpose of setting request attribute DC_cont is to allow construction of a cache ID that has a limited number of components and the purpose of setting individual request attributes DC_cont0, DC_cont1, ..., DC_contN is to allow construction of dependency IDs for more granular cache invalidations.
Since the member group information is not part of the session data, the cache filter has to retrieve this information from the database based on the user ID. In order to prevent performance degradation due to repeating database queries, the cache filter uses WebSphere Command Caching to accomplish this task. A new command - com.ibm.commerce.dynacache.command.MemberGroupsCacheCmdImpl - that extends directly from the WebSphere Command Framework is used to cache the member groups to which users belong, based on user IDs. WebSphere Commerce adds the following cache entry to the cachespec.xml to notify the dynamic caching service to cache this command:
<cache-entry> <class>command</class> <name>com.ibm.commerce.dynacache.commands.MemberGroupsCacheCmdImpl</name> <cache-id> <component type="method" id="getUserId"> <required>true</required> </component> </cache-id> <dependency-id>DC_userId</dependency-id> <dependency-id>DC_userId <component type="method" id="getUserId"> <required>true</required> </component> </dependency-id> </cache-entry>
WebSphere Application Server dynamic caching will cache the command object of class MemberGroupsCacheCmdImpl based on its get method getUserId() as its cache ID. Therefore, next time there is a request for member groups of the same user ID, dynamic caching will return the cached command object with an already computed member group. This member group information is then readily accessible using the command method getMemberGroups() which the cache filter calls to set the member groups for this user in the request attribute, DC_mg.
Note: WebSphere Commerce uses WebSphere Command Caching internally such as with MemberGroupsCacheCmdImpl in the cache filter above; however, WebSphere Commerce does not officially support WebSphere Command Caching of WebSphere Commerce commands.
Store page caching strategy
For information on caching considerations when designing your store pages see the topic "Creating store pages that can be cached" in the WebSphere Commerce Developer information center. This includes guidance on the following issues:
- What pages should be cached?
- Should whole pages or page fragments be cached?
- Developing a caching strategy
In addition, see the section discussing implications of store relationships in the topic "Creating store pages that can be cached" in the WebSphere Commerce Developer information center.