Cache invalidation after index builds
Cache invalidation is performed after an index is built. The kind of invalidation operation that is run depends on the type of indexing operation that was done.
Types of caches
The HCL Commerce Query and NiFi servers use several HCL caches, as described in HCL Cache Architecture. Most of the data stored in the caches is obtained by querying Elasticsearch indices. When indexed data are changed, the cache entries that used this data must be invalidated so that they can be refreshed with changed index data the next time they are used. For a complete description of the caching subsystem, see HCL Cache.
The default baseCache
is different from the other
caches. It is a servlet cache that contains cache entries as defined in the
cachespec.xml files for the Remote Store server, Transaction server, and Elasticsearch
Query application server.
Types of Invalidations
To help decide which cache entries are invalidated when index data changes, cache entries are tagged with dependency Ids.
You can tag cache entries in the baseCache
that
contain data specific to a category, product, or item in the
cachespec.xml file with dependency Ids that include the
category, product, or item Id. Use the invalidation template configurations format
defined for these dependency Ids in Fine-grained cache invalidation. Cache entries
tagged in this way are to be invalidated when index data for those categories,
products, and items are changed and corresponding fine grained invalidations are
issued. Ensure that these cache entries are also tagged with the
"WCT+FULL_ESINDEX"
dependency id, which is issued when fine
grained invalidations cannot be issued.
Cache entries in the baseCache
tagged with the
"WCT+FULL_ESINDEX"
dependency Id are to be invalidated when a
full index rebuild occurs, or when changes are made to the indexed data for which
fine grain invalidations are not issued. Cache entries in any of the caches used by
the Query and Nifi application servers tagged with the
"WCT+ESINDEX"
dependency Id are to be invalidated when any
change is made to any indexed data.
Index Update Scenarios
- Perform full reindex in the Authoring environment (typically through a scheduled job)
WCT+ESINDEX
andWCT+FULL_ESINDEX
are sent to the baseCache in the Authoring environment (Auth), and onlyWCT+ESINDEX
is sent to other caches used by the Query and NiFi application servers in Auth.- Perform incremental updates through Management Center in Authoring
WCT+ESINDEX
and fine grained invalidations are sent to thebaseCache
in Auth, and onlyWCT+ESINDEX
is sent to other caches used by the Query and NiFi application servers in Auth.- Perform Push-To-Live and Index a data feed into the Live environment through offline dataload
WCT+ESINDEX
and fine grained invalidations (based on the change history read from the workspace index) are sent to the baseCache in the Live environment (Live) and onlyWCT+ESINDEX
is sent to other caches used by the Query and NiFi application servers in Live. If fine grained invalidations are not issued for all the changes, theWCT+FULL_ESINDEX
invalidation are also sent to the baseCache in Live.