This blog promotes knowledge sharing through experience and collaboration. For more product information, visit our WebSphere Commerce CSE page. For easier navigation, utilize the Categories to find posts that match your interest.
Invalidating Cache: Marketing
Due to its personalized and dynamic nature, marketing data has always been tricky to cache and invalidate. In this post I discuss the invalidation techniques that are available on each Fix Pack and Feature Pack levels.
The marketing caches
For efficiency, marketing data is cached at different layers. There are required caches (DM_cache, CampaignInitiativeCache), JSP cache, and optional command and data caches. Even when JSP level caching is not used, the framework relies on the low level caches to reuse data and logic.
Some history (V6 and V7 pre-FEP5)
Before caching based on activity behavior became available with Feature Pack 5, besides the internal caches (DM_cache, CampaignInitiativeCache), a common technique was to cache the e-spot JSPs (e.g. ContentSpotDisplay.jsp) as a separate fragment, by using do-not-consume=true.
A common, but not too efficient technique, was to use time-based invalidations. This simple approach helped ensure some variation when the e-spot was assigned with multiple contents, and it also removed the staled entries after "not too long".
<cache-entry> <class>servlet</class> <name>/ConsumerDirect/Snippets/Marketing/Content/ContentSpotDisplay.jsp</name> <property name="do-not-consume">true</property> <property name="save-attributes">false</property> <cache-id> <component id="emsName" type="parameter"> <required>true</required> </component> <component id="DC_storeId" type="attribute"> <required>true</required> </component> <timeout>600</timeout>
Dynamic e-spots (different to each shopper) couldn't be cached at the JSP level and the cachespec.xml JSP fragment had to include do-not-cache=true.
An option for caching personalized content was added later on ( eMarketingSpotInvocationList.xml option, see Enabling JSP snippet caching), but it was never too popular.
Caching based on activity behavior
Feature Pack 5 solves the perennial issue of static vs dynamic caching. Static e-spots display the same content to all users (e.g. recommend a particular product on a category), while dynamic e-spots only apply to certain shoppers (e.g. have product x on the shopping cart). The Feature Pack 5 framework can balance performance by detecting the behavior of the e-spot (static vs dynamic) and automatically applying caching rules. Static e-spots are cached at the JSP level, while dynamic e-spots use lower level data and command caching.
If your store e-spot JSPs are enabled for caching based on activity behavior, no manual invalidation work is required. The stageprop utility automatically inserts the required invalidation Ids into the CACHEIVL table.
For more info, see Overview of e-Marketing Spot JSP caching based on activity behavior.
REST Marketing Services
If you enabled caching for REST marketing calls ( WebSphere Commerce REST API > Feature Pack 8 > espot ) using the sample cachespec.xml file (/CommerceServer70/components/foundation/samples/dynacache/REST/cachespec.xml), ensure you apply JR51650: Support invalidating e-Marketing Spot REST cache entries.
Invalidating after Stagingprop
In V6 and early V7, you were required to manually refresh the Marketing registry (CampaignInitiativeCache) after stagingprop for the updates to be reflected in the storefront. V7 Fix Pack 2/3 added new function to enable the use of the CACHEIVL table and the DynacacheInvalidation job to refresh registries. You can use wcs.cacheivl.trigger.sql to define database triggers to insert the specific data id (WCR+CampaignInitiativeCache) when the EMSPOT table is updated.
If you are using caching based on activity behavior, the registry refresh triggers are no longer required, and you can drop them. They are created whenever you run wcs.cacheivl.trigger.sql.