6.10.6 Cache servlet filtering and Commerce DC_ variables
Prior to WebSphere Commerce v5.5, WebSphere Commerce provided its own caching mechanism. Using the previous mechanism, Web pages could be cached based on either of two 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; 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 the servlet filter known as the cache filter. This cache filter is designed to set up the request attributes from the session information to be used by the DynaCache 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.
Table 6-5
| Request attribute | 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 | WebSphere Portal's adapter identifier |
| DC_buyCont | Buyer's eligible contracts (only valid for Supply Chain business model) |
| DC_userType | Type of logged on user (G/R/S) |
WebSphere Commerce-specific attributes
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 are 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 are 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.
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 command caching to accomplish this task. A command class called MemberGroupsCacheCmdImpl extends directly from the WebSphere command framework, and is used to cache the member groups to which users belong, based on user IDs.