The SDL Tridion Object Cache is an in-memory cache that stores frequently used objects from the Content Data Store. The cache keeps objects available to applications for repeated usage. This prevents SDL Tridion Content Delivery from having to retrieve objects from the Content Data Store for each request. Typically caching includes linking information, metadata and component presentations. The Object Cache is designed to significantly improve the performance of your Web sites and is available to every Content Delivery module. SDL Tridion recommends implementing it in every production environment.
The caching mechanism of SDL Tridion intercepts each request to an Item through the Broker API, for instance, a request for Linking Information. It then checks the internal cache for the presence of the requested item. If the item is present in the Object Cache, the item is served directly from there. If not, the item is retrieved from the Content Data Store and stored in the Object Cache before it is served back.
Figure 1 Caching request workflow
The cache home classes determine whether an item is cached or not. There is a cache home class for every type of object that can be cached. Please note that not all SDL Tridion items can be cached; the Tridion documentation provides details on the available cache home classes.
A cached item will be removed from the cache if one of the following conditions is met:
In the latter case, the invalidation message is delivered through the Cache Channel Service. The Cache Channel Service, or CCS for short, acts as an open channel between deployment and delivery of content to pass invalidation messages to all listening brokers. The SDL Tridion Broker manages the Object Cache, which is held in the same JVM memory as the Broker. Typically, the invalidation messages are passed using Remote Method Invocation (RMI), but they can also be passed using the Java Message Service (JMS). When each Broker starts, it subscribes to the CCS to ensure that it receives update messages. The Content Deployer also uses a Broker and subscribes to the CCS to push the invalidation messages. Once a new version of an SDL Tridion Item is deployed, a subscribing Broker picks up the invalidation message and the Object is removed from the Object Cache. This remote communication has been implemented because Brokers and the Deployer are usually in different JVMs or even on different servers.
Figure 2 Deployer communicating with the subscribing Brokers
You configure and control caching in the Broker configuration. In the Broker configuration file, you enable the cache by changing the following setting from:
Typically, you do not need to change other settings within the ObjectCache element. The Cache Bindings set the cache home classes for caching the SDL Tridion items and, on the whole, do not need changing. However, to communicate the cache invalidation messages between different JVMs you need to configure the Remote Synchronization and enable the CCS.
Running the Cache Channel Service..
#!/bin/sh java -cp ./lib/cd_core.jar com.tridion.cache.CacheChannelService
Typically, you should run the CCS from the same server as the Deployer and there should be one CCS per Deployer.
When you run the Java shell script or the Windows service, the CCS runs on port 1099 by default. To change the port, do the following:
#!/bin/sh java -cp ./lib/cd_core.jar com.tridion.cache.CacheChannelService localhost:3030
:cd_cacheservice.exe -install -host=localhost:3030
cd_cacheservice.exe -install -host=localhost:3030
Once you have your CCS running, you need to point all Brokers to the CCS to ensure that they receive cache invalidations. To do this, configure the Remote Synchronization section of the Broker configuration. In the default settings, this looks as follows:
<RemoteSynchronization Host="127.0.0.1" Port="1099" Queuesize="128" ServiceMonitorInterval="10000"/>
The settings of the Remote Synchronization are as follows (more information can be found in the Content Delivery Implementation Manual):
In addition to flushing the cache during a disconnection from the CCS it should be noted that the Object Cache will be flushed when the connection is reestablished. This is necessary to ensure that there is no stale content in the Object Cache.