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 that is 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.


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_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)
You 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.


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. 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 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. 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 do not do this, then it is possible the links on an SSL will go to non-SSL pages, thus causing a pop-up warning.

The following is equivalent to CommandContext.getter1().getter2():

<component id="CommandContext" type="attribute">

The following is an example of the isSecure attribute:

        <component id="" type="pathinfo">
        <component id="productId" type="parameter">
        <component id="DC_storeId" type="attribute">
        <component id="DC_lang" type="attribute">
        <component id="CommandContext" type="attribute">