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: Data Cache Invalidation IDs
Since Data Cache invalidation is self managed, you should not need to understand the underlying structure, but you may be curious about how Data Cache manages invalidations, or require additional information about this for your site tuning.
Data Cache invalidation IDs format in CACHEIVL
The Data cache dependency IDs are based upon which table is being cached, and what type of operation is performed to create this data. CACHEIVL entries are created by database triggers, and some Commerce processes, like Marketing or Solr. By default, CACHEIVL rows are created with a DATAID column value in this format:
Where x represents the type of operation that was performed, and the colName/colValue information is the unique index information about the record that was updated, so that the data cache can target the cache invalidation. An example DATAID column value could be WCT+CATENTRY+CATENTRY_ID:%:10501, which would signify that the CATENTRY table row with CATENTRY_ID 10501 was updated, but we are not sure what operation took place. The other operation symbols that can be used here are 'D' for deletes, or 'N' for a non-delete operation.
For more information on how CACHEIVL entries are created, you can review Websphere Commerce Documentation on this topic here: Invalidating WebSphere Commerce data cache entries
Data Cache invalidation processing
After the entries have been created in the CACHEIVL table, the DynacacheInvalidation scheduler job is used to invalidate their related cache entries. You may have noticed that the DATAID column values in CACHEIVL do not always exactly match the dependency IDs that are present in the cache monitor.
This entry has the following dependency IDs:
By making an update to this CATENTRY record in the database the database triggers will be activated, and will create this entry in the CACHEIVL table:
You may notice that this CACHEIVL record does not match any of the dependency IDs that are listed in the Cache Monitor for this particular catalog entry cache.
When DynacacheInvalidation runs, the following CATENTRY invalidations will be processed from this CACHEIVL row:
We can see that this will invalidate the entry from our cache monitor, since we have the matching dependency:
You may see more dependency IDs being invalidated, but in this example I am using reduceInvalidationIds on this site. For more information on this feature, please visit this article: Avoiding invalidation overload after propagations
Special invalidation IDs
Some dependency IDs exist for specific cache invalidation scenarios, to allow larger sets of data to be invalidated.
All entries in the data cache have this common dependency ID. It is used for cache clears.
This dependency ID is associated to all data cache entries for a particular table. It's issued to invalidate the complete table.
Cache entries only subscribe to this dependency ID if they do not subscribe to individual dependency IDs. This invalidation is always executed when there is a change in the table to invalidate all of the cache entries that are not tracking individual dependency IDs.