Distributed Caching

In a multi-server installation, each server running the Content Store has its own set of caches, and all these caches must be synchronized with each other to some extent. Specifically, whenever a change is made that can potentially cause an item in a cache to become invalid, that change must be reported to all servers, so that the appropriate caches can be checked and the invalid item can be removed, if necessary. The basic mechanism is that the Content Store generates an event each time a potentially cache-invalidating change is made. At the same time, the Content Store also listens for such events generated by other Content Store instances, and when it receives such an event, checks the appropriate cache and if necessary, removes the invalid item.

There are, however, two ways to set up distributed caching:

In a typical multi-server installation, different servers have different functions. There are two basic server types:

Publishing servers

A publishing server is a 'back-end' server used by editorial staff to create and modify publication content using CUE.

Presentation servers

A presentation server is a 'front-end' server used to serve publication content.

As a general rule, therefore, a publishing server is a change-generating server, and a presentation server is not. This is, however, not always the case, since some publications include functionality that enables "reader participation" of one kind or another. If the Forum plug-in is installed, for example, then presentation servers will also be change-generating servers.

For multi-server setup, you should make sure to set the escenic.server system property on all your Content Store instances. Each Content Store instance should have this property set to its own host name or IP address.