Administer > Dynamic caching


Store relationships for cached store pages

If the store is using data defined in another store through a store relationship, use the request attributes specified by the cache filter to define the relationships. The cache filter is a servlet filter that defines request attributes from the session and store relationship information that can be used by the WebSphere Application Server dynamic cache. The dynamic cache then uses this information to construct cache IDs and dependency IDs to be used for cache invalidation.

The cache filter creates the store relationships information by calling the getStorePath() and getStoresForRelatedStore() methods from the StoreAccessBean. The corresponding information is listed in the following table:

Store Relationship Type Store Relationship Identifier Request Attributes Name for getStorePath() Request Attributes Name for getStoresForRelatedStore()
IBM commerce businessPolicy -1 DC_busN DC_bus_RS_N
IBM commerce business campaigns -3 DC_campN DC_camp_RS_N
IBM commerce business catalog -4 DC_catN DC_cat_RS_N
IBM commerce business command -5 DC_cmdN DC_cmd_RS_N
IBM commerce hosted store -6 DC_hostN DC_host_RS_N
IBM commerce price -7 DC_prcN DC_prc_RS_N
IBM commerce referral -8 DC_refN DC_ref_RS_N
IBM commerce segmentation -9 DC_segN DC_seg_RS_N
IBM commerce URL -10 DC_urlN DC_url_RS_N
IBM commerce view -11 DC_viewN DC_view_RS_N
IBM commerce inventory -13 DC_invN DC_inv_RS_N
IBM commerce base item -14 DC_baseItemN DC_baseItem_RS_N
IBM commerce channel store -15 DC_chsN DC_chs_RS_N
IBM commerce currency conversion -17 DC_currConvN DC_currConv_RS_N
IBM commerce currency format -18 DC_currFmtN DC_currFmt_RS_N
IBM commerce supported currency -19 DC_supCurrN DC_supCurr_RS_N
IBM commerce counter value currency -20 DC_cterCurrN DC_cterCurr_RS_N
IBM commerce measurement format -21 DC_meaFmtN DC_meaFmt_RS_X
IBM commerce contract -22 DC_contractN DC_contract_RS_N


Store relationship caching example

To understand how caching pages that use a store relationship works, consider the following example.

Publish the sample composite store archive DemandChain.sar and then creating a store (for example, ResellerOne) in that site creates the following stores.

Store ID Directory Store Type
10001 CommercePlaza channel hub
10002 CommercePlazaCatalog catalog asset store
10003 CommercePlaza distributor proxy
10004 ConsumerDirectResellerProfile storefront asset store
10051 ResellerOne reseller store

ResellerOne (10051), the reseller store, uses the assets defined in the storefront asset store (10004) and the catalog asset store (1002).

In order to set up the caching relationship, the cache filter gets the following information:

Store ID Relationship Type getStorePath() getStoresForRelatedStore()
10001

  • -1 (business policy)

  • -4 (catalog)

  • -7 (price)

  • -17 (currency format)

  • -19 (currency supported)

10002 not applicable
10001

  • -6 (hosted store)

10051 not applicable
10051

10051, 10002, 10004 10051
10051

  • -3 (campaigns)

  • -5 (command)

  • -10 (URL)

  • -11 (view)

10051, 10004 10051
10051

10051, 10002 10051

Then the cache filter sets up the following request attributes:

Store Relationship Store ID 10051 store ID 10051 store ID 10001
-1 (business policy) DC_bus0=10051 DC_bus1=10002 DC_bus2=10004 DC_bus_RS_0=10051 DC_bus0=10002
-2 (tax) DC_tax0=10051 DC_tax1=10004 DC_tax_RS_0=10051  
-4 (catalog) DC_cat0=10051 DC_cat1=10002 DC_cat_RS_0=10051 DC_cat0=10002
-6 (hosted store) DC_host0=10051 DC_host_RS_0=10001 DC_host0=10051

Whenever the catalog of the catalog asset store (10002) is changed, the catalog pages of the ResellerOne store (10051) must also be invalidated before it can use the information from the catalog asset store (10002). In order for the pages in 10051 to be invalidated, extra dependency IDs must be set up for this store relationship. Setting up the extra dependency IDs for StoreCatalogDisplay is illustrated in the following example: 

<!-- Start Store Relationship Dependency Ids --> 
<!-- DC_cat1 is the catalog Profile Store ID --> 
<dependency-id>storeId
       
<component type="attribute">                
   
<required>true</required>        
   
</component>
</dependency-id> 
<dependency-id>storeId:catalogId
       
   
<component type="attribute">                
   
<required>true</required>        
   
</component>        
   
<component type="attribute">                
   
<required>true</required>        
   
</component>
</dependency-id> 
<dependency-id>StoreCatalogDisplay:storeId
       
   
<component type="attribute">                
   
<required>true</required>        
   
</component>
</dependency-id> 
<!-- Ends Store Relationship Dependency Ids -->

The extra dependency IDs created are...

Once these extra dependency IDs are defined, where there are changes to the catalog asset store 10002 that cause the catalog asset store pages to be invalidated, the hosted store (10051) pages will also be invalidated.

Related reference

Cache defaults


+

Search Tips   |   Advanced Search