Dispatcher Cache Invalidation – A Race condition to be aware of

The default option for configuring dispatcher cache flushing is to configure the flush agents on the Author similar to the replication agent configuration. Have one flush agent configured for each dispatcher in the environment.

When a content gets activated, a request gets queued for each dispatcher flush agent configured and cache flush requests would be sent to the dispatcher based on the queue items asynchronously.

This is a simple configuration to do and maintain with all the configuration getting managed on the Author. But be aware that this way of dispatcher cache flushing might lead to a race condition.

This is because both the replication and dispatcher cache flushing happens asynchronously and the order of completion of each event is not guaranteed.

Consider a simple scenario where we have one author, one publisher and one dispatcher in the configuration. When a page is activated, requests for replication to publisher and flushing for the dispatcher cache gets placed and are processed asynchronously.

Now with the order of processing of these two events not guaranteed, it would result in one of the following two possibilities

• Replication to the publisher happens first followed by the flushing of dispatcher cache
• Flushing of dispatcher cache happens first followed by the replication to the publisher

The first scenario is the desired behavior, but the second scenario could result in a race condition if between the flushing of dispatcher cache and replication to the publisher, a user request happens for the resource being flushed

This scenario is depicted in the below diagram where a user request happens in-between dispatcher cache flushing and replication to publisher

In this scenario the user request is forwarded to the publisher as the content for the requested  resource on dispatcher is already flushed. Now the publisher would serve the older version for the content as replication for the modified content has not happened on the publisher yet.

The dispatcher would consider this version as new content and use it for all subsequent requests and would not be aware of subsequent replication completion on the publisher side.  

For this reason, for any non-trivial application its highly recommended to configure the dispatcher flush agents on the publisher side and trigger the flush action from publisher through chain replication mechanism.

The same scenario with dispatcher flush agents configured on the publish instance is depicted in the diagram below

In this case, requests from the user between step 1 & 2 would get the older version of the content from cache. Step 2 would flush the dispatcher cache and requests made after step 2 will fetch the new content from publish and cache it for subsequent requests, thus eliminating the race condition

Configuring the flush agents on publishers is not without its challenges. We will explore the challenges with arriving at the optimal design for configuring dispatcher flush agents on publish instances in the next blog here