Administer > Dynamic caching > Prepare to use caching in WebSphere Commerce
Cache identifiers
When the dynamic cache service places an object in the cache, it labels it with a unique identifying string known as a cache ID. The cache ID is constructed according to <cache-id> rules specified in the <cache-entry> elements. The <cache-id> rules define how to construct cache-ids from information associated with an application server request.
The <cache-id> is formed from a list of <components>. There are several different types of components that are available to build these cache-ids.
DC_RequestAttributes
A servlet filter known as the cache filter enables the dynamic cache to use session information to construct the cache ID. The cache filter is designed to set up request attributes from the session data, MemberGroupsCacheCmd, and store relationship information. Dynamic cache can use the request attributes as component elements.
To access these components, set the type of the component to attribute and the value set to one of the defined DC values.
The following table lists the request attributes that are set by the cache filter:
Request attributes Description DC_aorg User's active organization. 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)
Session method calls
Cache-ids are composed from values that are in the WebSphere Application Server session. To access these values, specify a component type of session and use the value that is the name of the object in the session.
Cookies
Cache-ids components may access the values of named cookies.
To access one of these cookies in a component, specify the component type as cookie with a value that matches the name of the cookie.
The use of cookies does limit this component to Web-specific scenarios. You cannot use this component with other protocols, such as Web services.
ESI caching does not allow request attributes. In this case, cookies are useful to store session information such as language ID, preferred currency ID, parent Organization, contract ID, and member group.
Command context method calls
It is possible to access parameters available in the CommandContext. Specifically, you can invoke methods on the CommandContext object so that certain values are accessed that would not be available.
To achieve this, set the type of the component to attribute, and in addition to the required child element, there is an additional child element called method. The method element identifies which method is invoked. You can have nested method tags.
An important CommandContext method is isSecure(). It is important to cache separate entries for the browse pages in SSL and non-SSL to ensure that the links are in the correct format (for example, SSL pages link to other SSL page and vice versa). If you don't do this, then it's possible the links on an SSL will be to non-SSL pages, thus causing a popup warning.
The following is equivalent to CommandContext.getter1().getter2():
<component id="CommandContext" type="attribute"> <required>true</required> <method>getter1 <method>getter2</method> </method> </component>
The following is an example of the isSecure attribute:
<cache-id> <component id="" type="pathinfo"> <required>true</required> <value>/ProductDisplay</value> </component> <component id="productId" type="parameter"> <required>true</required> </component> <component id="DC_storeId" type="attribute"> <required>true</required> </component> <component id="DC_lang" type="attribute"> <required>true</required> </component> <component id="CommandContext" type="attribute"> <method>isSecure</method> <required>true</required> </component> </cache-id>
Related tasks
Related reference