What is the SDL Tridion Object Cache?

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.

How does it work?

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.

Invalidation of the cache

A cached item will be removed from the cache if one of the following conditions is met:

  1. The object is the oldest according to the Least Recently Used caching policy and space is needed in the cache for a new object  
  2. The cached object is invalid because a new version of the SDL Tridion Item or one of its dependencies has been deployed 

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

Setting up and configuring Object Caching

You configure and control caching in the Broker configuration. In the Broker configuration file, you enable the cache by changing the following setting from:

<ObjectCache Enabled="false">

to

<ObjectCache Enabled="true">

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.

Setting up the Cache Channel Service

Running the Cache Channel Service..

  • On Windows, when you install Content Delivery, the CCS is automatically installed.  
  • On Java-based environments, run the service from a shell script as follows:

#!/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.

Setting the port for Cache Channel Service

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:

  • On Java-based environment, change the shell script as follows: 

#!/bin/sh 
java -cp ./lib/cd_core.jar com.tridion.cache.CacheChannelService localhost:3030

  • On, Windows uninstall the Windows service and reinstall it with the command

:cd_cacheservice.exe -install -host=localhost:3030

Pointing the Broker to the CCS

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):

  • Queuesize - The size of this cache's event queue. This defaults to a maximum size of 128 events.
  • ServiceMonitorInterval - The amount of time that the Content Broker waits between checks to see if it can still establish communication with the CCS. When communication is lost, any actions you perform within this time frame will not be synchronized. The value defaults to 60 seconds.
  • FlushCacheDuringDisconnectInterval - If the Content Broker loses the connection to the Cache Channel Service or J2EE server, it continues to cache items while disconnected. This attribute specifies how often the cache should be flushed while the connection is unavailable. Possible values for this attribute are:
    • -1: (default value) the cache is not flushed at all while the connection is lost.
    • 0: the cache is flushed as soon as the connection is lost. No caching is done while the connection is unavailable.
    • a number equal to or higher than the value of ServiceMonitorInterval. After the connection is lost, the Content Broker immediately flushes the cache, and continues to flush at the interval specified. 

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.