Cache Management allows to manage caches by using a common API for:
The API is provided by the CacheEngine which supports the following processes:
The Cache Management API was implemented by using the following paradigms:
Caches are located at different layers of the product. Within one layer different groups of caches can exist.
Caches must be assigned to cache groups. Note that not all caches are caches in a narrow sense, there are pseudo-caches which just behave like classical caches in some aspects; e.g., search indexes are based on data, and when this data changes, the search indexes must be updated.
The ORMCacheGroup is located at the platfrom layer and contains one cache instance which represents the ORMCache used to cache persistent objects in the JVM memory of an application server.
Please check Concept - ORM Layer for more details regarding the ORMCache.
The ObjectCacheGroup is located at the business layer and contains an arbitrary number of cache instances which are global per JVM, used to cache Java objects in the JVM memory of an application server.
The SearchIndexRebuildableCacheGroup is located at the application layer and contains one pseudo-cache instance which is used to rebuild/update and reload search indexes. Search indexes are stored in the shared file system.
Please check CO Search Services (until 6.6.x) and Concept Search Services (since 6.7) for more details regarding the Search Framework.
The SearchIndexReloadableCacheGroup is located at the application layer and contains one pseudo-cache instance which is used to reload search indexes without rebuild/update. Search indexes are stored in the shared file system.
Note that this group is relevant in the mass data replication scenario only. Search index data is assumed to be in a consistent and updated state on EDIT and it is just replicated to the LIVE system, followed by a search index reload action.
The PageCacheGroup is located at the presentation layer and contains one pseudo-cache instance which is used to invalidate the webadapter page cache which is stored in the webadapter's page cache file system.
The CacheEngine supports keyword-based invalidation. Please check Concept - Page Cache for more details regarding the PageCache.
One entity could be cached in different cache groups at the same time, e.g. a product is cached in the ORMCache, it is contained in a search index and its storefront page is contained in the page cache. The CacheEngine - i.e., a certain CacheClearProcessor - clears the caches in a consistent way by clearing the caches in the order of cache groups.
The following order is used: ORMCacheGroup, ObjectCacheGroup, SearchIndexRebuildableCacheGroup / SearchIndexReloadableCacheGroup, PageCacheGroup.
There are two ways of clearing a cache:
A concept is necessary to be able to identify which objects must be removed from a cache. The CacheEngine uses so-called "CacheClearKeys" for that. A CacheClearKey identifies an object, a class of objects or the domain of objects to be removed from caches.
A CacheClearKey is different from a CacheKey! A CacheKey is used by a cache to store and lookup a cached object while a CacheClearKey is used by a cache to identify objects which must be removed from the cache.
The following types of CacheClearKeys are available:
For each kind of object the appropriate CacheClearKeys must be provided. This is done by CacheClearKeyProviders which are registered at the CacheEngine and used by CacheClearProcessors.
There are different times when caches have to and can be cleared. Cache clear can be done instantly when objects have been changed or it can be done later by batching the cache clear. Depending on the type of processor and performance aspects, not all CacheGroups are necessarily assigned to a processor. A processor collects the CacheClearKeys with the help of the CacheClearKeyProviders assigned to the CacheEngine. Processors may also differ in the way cache clear messaging is done in a clustered environment with more than one appserver.
An InstantCacheClearProcessor clears caches of all CacheGroups assigned to it immediately.
A BatchCacheClearProcessor uses a two-phase mechanism to clear caches: On each batchCacheClear request the CacheClearKeys are stored in the database for a context. This context is described by a virtual UUID used to identify the process the processor is used for, e.g. an import process. Once all CacheClearKeys are stored, cache clear can be requested and caches of all CacheGroups assigned to the processor are cleared immediately for the CacheClearKeys previously batched for the virtual UUID.
A second mechanism is supported by this type of processor: Cache clear can be batched for a desired cache clear date. A scheduled job named "ProcessBatchCacheClear" exists which runs at intervals and clears caches for all CacheClearKeys previously batched for a desired cache clear date < current date.
This processor clears the ORMCacheGroup and ObjectCacheGroup only. It does not use a dedicated messaging channel to inform other appservers about the cache clear. Instead, the messaging mechanism provided by the ORMEngine's SynchronizationManager is used. The SynchronizationManager does UDP multicast for the intershop.cacheSync channel - configurable in <eserver>/share/system/config/cluster/orm.properties-per default. Note that this channel is usually disabled after installation. It has to be enabled and configured properly when more than one appserver is used.
This processor clears the SearchIndexRebuildableCacheGroup and PageCacheGroup only. Since the cache location of a SearchIndex is the file system, search indexes are always updated by the appserver which issued the cache clear request only. Afterwards, the search indexes are simply reloaded on other appservers by sending a search index reload message. For the PageCacheGroup no messaging is necessary at all, the page cache is invalidated using the keyword-based approach and it is up to the WebAdapterAgent to perform the concrete invalidation.
This page cache clear does not remove cached files; it just invalidates the cached files by changing the timestamps.
Messaging for search index reload is done by the SearchIndexRebuildableCache instance; it uses a dedicated messaging channel and a special SyncMessenger implementation to inform other appservers about the cache clear. The SyncMessenger provides a mechanism to send a message to other appservers and wait for message responses from those appservers. For sending another messenger - per default a UDP multicast messenger - is wrapped and used. The SyncMessenger waits for responses by checking a special table in the DB where every receiving appserver is supposed to commit a row when the message has been received and successfully handled. The SyncMessenger does not wait forever; therefore, a timeout has to be configured - it defaults to 10s. If an appserver did not respond within this timeout, the message and the complete cache clear process is considered as failed. The SyncMessenger has to be configured in <eserver>/share/system/config/cluster/cache.properties.
Note that the ORMCacheGroup and ObjectCacheGroup are still cleared during import processes because the ORMCacheSyncCacheClearProcessor is used during import automatically if an ORM-based import approach is used.
Note that the ImportBatchCacheClearProcessor is currently used during product import and catalog import only.
This processor clears the ORMCacheGroup, ObjectCacheGroup and SearchIndexReloadableCacheGroup after mass data replication on the live system only. It uses the same SyncMessenger as the ImportBatchCacheClearProcessor - please check the previous chapter for details. Note that after this processor finished, a complete page cache clear is done by the staging framework on the live system. This is not done via the Cache Management API but by the staging framework itself because the page cache can be rolled back to the previous state when a replication process is undone. This special feature is not yet supported by the Cache Management API.
This page cache clear is different from a keyword-based invalidation because it creates a fresh page cache directory for each site were data was replicated for.
This processor clears all available cache groups (ORMCacheGroup, ObjectCacheGroup, SearchIndexRebuildableCacheGroup, PageCacheGroup) immediately. It uses the same SyncMessenger as the ImportBatchCacheClearProcessor - please check the previous chapters for details. This processor is not directly related to a certain framework, it can be used at various places. Please keep in mind that InstantCacheClearProcessors do not store cache clear keys in the DB, instead the keys are transferred as part of the cache clear message issued by the SyncMessenger. When the SyncMessenger uses a MulticastMessenger for sending messages, the size of a message might be limited. It is not recommended to use this processor for a lot of cache clear keys and it is not recommended to use this processor in a mass data scenario. The GenericBatchCacheClearProcessor is available if a lot of cache clear keys must be handled or if mass data is processed.
This processor clears all available cache groups (ORMCacheGroup, ObjectCacheGroup, SearchIndexRebuildableCacheGroup, PageCacheGroup) by batching the cache clear keys first. It uses the same SyncMessenger as the ImportBatchCacheClearProcessor - please check the previous chapters for details.
The information provided in the Knowledge Base may not be applicable to all systems and situations. Intershop Communications will not be liable to any party for any direct or indirect damages resulting from the use of the Customer Support section of the Intershop Corporate Web site, including, without limitation, any lost profits, business interruption, loss of programs or other data on your information handling system.