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>. Several different types of components are available to build these cache-ids.
DC_RequestAttributes
A servlet filter that is 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_curr User's preferred currency DC_lang User's preferred language DC_cont User's current contract DC_storeId Store ID DC_userId User's identifier DC_userType Type of logged on user (G/R/S) DC_storeIdentifier Store identifier We can create custom request attributes to construct cache identifiers. For more information about creating custom request attributes, see Custom request attributes for servlet caching.
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 can 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. We 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, we can start 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 another child element called method. The method element identifies which method is started. We 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 do not do this, then it is possible the links on an SSL go to non-SSL pages, thus causing a pop-up 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 isSecureattribute:
<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 concepts
Caching strategy
Related tasks
Configure cacheable objects