You can optimize a site’s performance after a switch deployment by enabling selective cache invalidation on target repositories. A repository that is thus configured invalidates its item caches selectively during deployment, rather than invalidating the contents of those caches entirely.

If enabled:

Only those cached items that change as a result of the deployment are invalidated. All other cached items remain unchanged. Because selective invalidation increases deployment overhead, you might want to configure a threshold for the number of invalidated items. On exceeding that threshold—the sum of all changed items in a deployment—the selective invalidation process is skipped and the deployment invalidates all cached items in the target repositories.

If not enabled:

Item caches of all deployed repositories are invalidated. This can result in slow response time to initial requests, as fresh data is obtained directly from the database.

Constraints

Two general constraints apply to usage of selective cache invalidation:

Configuration Steps

You configure selective cache invalidation on the production server and the asset management server, as follows:

Excluding Repositories and Item Descriptors

A production site publishing agent can be configured to exclude specific repositories and item descriptors from selective cache invalidation—in other words, require that item caches be fully invalidated on each deployment. To do so, set the property fullInvalidationRepositoryPaths in this component:

/atg/epub/sci/AgentSCIThresholdController

You set this property as follows:

fullInvalidationRepositoryPaths=\
   repository-path[=item-descriptor[;item-descriptor]...] \
   [,...]

If no item descriptors are supplied, all item caches in the repository are invalidated. The property can specify multiple comma-delimited repositories, and each repository can specify multiple semi-colon-delimited item descriptors.

For example:

fullInvalidationRepositoryPaths=\
   /atg/commerce/catalog/ProductCatalog=category;product

Invalidating Caches after Deployment

One of the post-deployment tasks that occur is the invalidation of caches. System defined caches, such as the PMDLCache and PriceCache use the DeploymentMethodInvocationService to perform this validation.

The DeploymentMethodInvocationServies can also invalidate non-repository caches, or perform other similar invalidation actions after deployment occurs. If you have a custom cache, or a custom implementation of atg.service.cache.Cache, you can use this service to flush the cache after deployment.

To set up invalidation, perform the following steps:

The following are examples of the custom components used to configure the invalidation process.

As described above, the first step is to configure a component using the class atg.deployment.agent.
DeploymentMethodInvocationPolicyImpl. The following is an example of MyCustomPolicy:

# My custom policy for invalidating my custom cache after changes are deployed.
#

$class=atg.deployment.agent.DeploymentMethodInvocationPolicyImpl

object=/atg/commerce/custom/MyCustomCache
methodName=flush
deploymentState=DONE_ACTIVATE
failDeploymentOnInvocationError=false
active=true
repository=/atg/commerce/custom/Customizations
itemTypes=profile

The second step of the configuration process is to append your new component to the DeploymentMethodInvocataionServices, which may be configured similarly to the following:

# A deployment event listener that can be used for invoking arbritrary methods
# on arbritrary objects during the course of a deployment. To invoke a method add
# an atg.deployment.agent.DeploymentMethodInvocationPolicy
# component to deploymentMethodInvocationPolicies property of this component.
#

$class=atg.deployment.agent.DeploymentMethodInvocationService

deploymentMethodInvocationPolicies+=\
                                  DropletCacheInvalidationPolicy,\
                                  SitemapGenerationPolicy,\
                                  MyCustomPolicy

For additional information, refer to the ATG Platform API Reference.