Caching

This section provides an introduction to the specific caching features and possibilities in EPiServer Commerce, including Commerce-specific caching and examples of how EPiServer Commerce uses caching for its product catalogs and their entries. Platform cache functionality, including remote synchronization, is part of the EPiServer platform. Refer to the Caching section in the EPiServer CMS SDK for more information.

Classes referred to here are available in the following namespaces:

• Mediachase.Commerce.Catalog

Subsystem caching

Caching for each subsystem such as catalogs and orders, is configured in their respective configuration files. For catalogs for example, you will want to refer to ecf.catalog.config in the configs folder of the site.

Example: cache settings for the Catalogs subsystem

XML

<Cache enabled="true" collectionTimeout="0:1:0" entryTimeout="0:1:0"nodeTimeout="0:1:0" schemaTimeout="0:2:0"/>

The collectionTimeout responds to an entry array, and "entry" responds to a single entry. What is actually cached is the CatalogEntryDto, and since the Entry object is created from the DTO, the DTO is what we will cache to here. In some cases, the entry objects themselves can also be cached rather than the DTO.

Cache invalidation

In the catalog example, the cache is invalidated when it reaches the cache timeout specified above for the request type. It can also be invalidated if the entire catalog cache is cleared by calling CatalogCache.Clear(). That is automatically called when calling CatalogContext.SaveCatalogEntry.

[New in 8.9.0]

From version 8.9, updating catalog objects no longer automatically calls CatalogCache.Clear(). Instead, cached items are evicted from cache when a related catalog object is updated. CatalogCache has also been rewritten to use the EPiServer ISynchronizedObjectInstanceCache, which means that any items evicted from cache on one of the site's servers will also be evicted on any other server (including the server running Commerce Manager). The exception is CatalogCache.Clear() which will only clear the cache on the local server.

Custom objects inserted into the cache may also be automatically evicted from the cache when related catalog objects are updated. This is accomplished by getting the appropriate keys from CatalogCacheKeys and using them in the CatalogCache.Insert method's masterKey paramter. You may also work directly with ISynchronizedObjectInstanceCache and using these keys as master keys in the CacheEvictionPolicy. In this case you should include CatalogCacheKeys.RootKey (which is automatically included if you use CatalogCache.Insert).

Below is an example using CatalogCache:

C#

var entryId = 1;
var catalogContext = ServiceLocator.Current.GetInstance<ICatalogSystem>();
var entryDto = catalogContext.GetCatalogEntryDto(entryId);
var myObject = ProcessEntry(entryDto.CatalogEntry.FirstOrDefault());
var myCacheKey = "MyObjectCacheKey";
var masterKeys = new[] {CatalogCacheKeys.GetEntryKey(entryId)};
CatalogCache.Insert(myCacheKey, myObject, masterKeys, new TimeSpan(1, 0, 0));

The object inserted will stay in the cache for up to one hour, or until the catalog entry with id 1 is updated.

It is also possible to get a cache item evicted without knowing the id(s) of the items it depends on. For instance, a cache object that depends on the CatalogCacheKeys.AnyEntry key will be evicted when any catalog entry is updated. Think through what keys you should depend on. If you for instance are caching a search result or a listing the result will depend on the relations of the entries and not just the entries themselves so you probably want to add CatalogCacheKeys.AnyNodeRelation or CatalogCacheKeys.GetNodeRelationKeyForEntry(entryId) to the master key dependencies.

See also

• Configuration section in this documentation, for more information on configuration files in EPiServer Commerce.
• The Caching section in the EPiServer CMS SDK.