Introduced in Feature Pack 2

Setting up dynamic cache invalidation for prices generated by price rules

Set up dynamic cache invalidation so that prices set by price rules are refreshed on store pages when business users change a price rule, a price equation, a price constant, or a price rule assignment.

About this task

To set up this type of cache invalidation, you must make the following updates to the cachespec.xml file for your store:
  • Merge in the invalidation rules that WebSphere Commerce provides in a sample cachespec.xml. These invalidation rules generate invalidation IDs when price-rule-related changes occur.
  • Add the related dependency IDs to any cache entries that cache price-related information from price rules.

The following procedure provides detailed steps.

Procedure

  1. Review the sample cachespec.xml file that is available within your production environment. This sample file contains the invalidation rules for price rules:
    • WebSphere Commerce EnterpriseWC_installdir/components/management-center/samples/dynacache/invalidation/pricerule/cachespec.xml
  2. Review a sample cachespec.xml file for a WebSphere Commerce starter store to see how the dependency IDs are defined for cache entries that cache price-related information:
    1. Open the cachespec.xml sample for your store:
      • WebSphere Commerce DeveloperWCDE_installdir/samples/dynacache/store_name/cachespec.xml
      • WebSphere Commerce EnterpriseWC_installdir/samples/dynacache/store_name/cachespec.xml
      Where store_name is the name of you store directory.
    2. To see where and how the dependency IDs are defined in this sample file, search for:
      priceRule:storeId
  3. Using the samples that you reviewed as reference, make the necessary changes to the cachespec.xml file for your store:
    1. Open the cachespec.xml file for your store:
      • WebSphere Commerce DeveloperWCDE_installdir/workspace/stores/WebContent/WEB-INF/cachespec.xml
      • WebSphere Commerce EnterpriseWC_eardir/Stores.war/WEB-INF/cachespec.xml
    2. Merge in the following invalidation rules (this code snippet comes from the cachespec.xml sample you reviewed in step 1):
      <cache-entry>
          <class>command</class>
          <sharing-policy>not-shared</sharing-policy>
          <name>com.ibm.commerce.contract.tc.commands.ContractTCSaveCmdImpl</name>
          <name>com.ibm.commerce.price.facade.server.commands.ChangePriceRuleCmdImpl</name>
          <name>com.ibm.commerce.price.facade.server.commands.ChangePriceConstantCmdImpl</name>
          <name>com.ibm.commerce.price.facade.server.commands.ChangePriceEquationCmdImpl</name>
          <property name = "delay-invalidations">true</property>
          <invalidation>
              priceRule:storeId
              <component id = "getPriceRuleReferencedStoreIds" type = "method" multipleIDs = "true">
                  <required>true</required>
              </component>
          </invalidation>
      </cache-entry>
    3. Add the following dependency ID code to each cache entry that caches price-related information from price rules:
      <dependency-id>priceRule:storeId
          <component id = "storeId" type = "parameter" multipleIDs = "true">
              <required>true</required>
          </component>
      </dependency-id>
    4. Save and close the cachespec.xml file.
  4. If you are using a staging server, or a utility such as the massload utility, ensure that the cached data that is being retrieved is not stale or invalid by enabling the following database triggers:
    • WebSphere Commerce DeveloperWCDE_installdir/components/foundation/schema/fep2/DB_type/wcs.cacheivl.trigger.sql
    • WebSphere Commerce EnterpriseWC_eardir/components/foundation/schema/fep2/DB_type/wcs.cacheivl.trigger.sql
    These database triggers cause specially formulated invalidation IDs to be appended to the CACHEIVL database table, in the DATAID column. The DynaCacheInvalidationCmd scheduler job processes the CACHEIVL rows and issues appropriate cache invalidations. When this technique is used, there is a delay between when the database changes are made and when the DynaCacheInvalidation scheduler job performs the invalidations. During that time period, the old cached data is used.