|Number of votes:||8|
TL;DR: Episerver Commerce 11.1 contains improved caching strategies for Catalog Content allowing site implementations to make better use of the available memory.
Episerver Commerce uses a Content Provider to make catalog data available through the Content API, which is the recommended API to use in site implementations. The Catalog Content Provider uses the low-level catalog DTO and MetaObject APIs to construct the Content instances.
These low-level APIs are also public and have their own cache, which means several representations of the same base data will be cached when loading Content. However, a site implementation built using the Content APIs is unlikely to, at least frequently, use the low-level APIs to access the same catalog data.
Because of this, in Commerce 11.1 the caching strategies have been changed so that when the low-level APIs are used by the Catalog Content Provider, only the Content is inserted into the cache. Similarily, when using the IRelationRepository and IAssociationRepository APIs, only the high level Relation/Association objects are cached, not the underlying DTOs. If an implementaton uses the low-level APIs directly, the caching strategies are the same as before.
As you may have realized, this doesn't really decrease the memory usage at the time of loading Content from the database, as the DTO and MetaObject will still have to be allocated. The difference lies in how quickly that memory can be recovered and reused. Before this change, the DTO and MetaObject wouldn't go out of scope until they were trimmed from cache, and by the time they were trimmed they may have been promoted to the garbage collection generation 1 or 2 making it harder to recover the memory. With this change, they will go out of scope quickly and can easily be garbage collected, allowing the application to make better use of the available memory, for example holding more Content items in cache and reducing the cache churn.