Selective Cache Invalidation in ATG

Selective cache invalidation functionality is introduced as part of ATG 10.X.

What is selective Cache invalidation? 

Selective cache invalidation is a process where only a set as repository item are removed from the cache (RAM Memory) which are modified and deployed as part of the BCC deployment.

Why we should go for selective Cache invalidation?

As we know caching of a repository item plays important in the performance of a site. As we know databases operation are very costly operations. Data related to catalog items are not changed by any agent JVMs. We can go head and cache them which save the time and increase the performances.

ATG system early than 10.X used to invalidate the cache completely when it performs any deployment. Than it will take some time to regain the cache once more, and still the cache is brought back site would be relatively slow.

Imagine the a case when deployment are more frequent and for a small data change, even for small data change the change is invalidated complete from the store JVM.

The Selective cache invalidation play an important role for these kind of activity, whether only the repository item is removed from cache which is get modified as part of deployment.

What is Cache warm up?

Cache warm up is activity when is performed after the selective cache invalidation. Part of this process the item which is removed from cache is loaded once more in the cache by calling the get Item for those repository items.

Selective Cache invalidation and cache warm up will make sure the cache is not impacted and the modified data is also refreshed in cache also.

How do we turn on the selective Cache invalidation and Cache warm up?

We have following flags to turn on the selective cache invalidation.

• <Reposioty Item Component>.selectiveCacheInvalidationEnabled=true
• /atg/epub/DeploymentAgent.cacheWarmingEnable=true
• /atg/epub/sci/ServerSCIThresholdController. threshold =  <max number of item which selective cache should be performed>

"Threshold" is to determine after what number of count the system should go for full cache Invalidation. As selective cache invalidation of huge number of record will take more time and will not serve the purpose.