Custom Cache Invalidation using JMS

Let's say you have your own application or a custom cache that stores some Tridion items for better performance. You are not relying solely on the Tridion object cache, and you built your own cache layer on top of it. You don't want to serve stale content or use a dummy time-to-live cache, and you chose an elegant dependency cache implementation. This implies you need to intercept the cache 'invalidate' messages from the Tridion Deployer and use them to remove the updated items from your custom cache.

This is exactly the setup I happen to have -- DD4T Java web-application using RESTful services providers. The DD4T application makes no use of Tridion APIs whatsoever, everything being abstracted in the services layer. The DD4T factories call the service-based providers and cache the returned models in a local EHCache. Naturally, I need an elegant cache notification mechanism to flush the items in the EHCache that are updated by a publish action. The Cache Channel Service is JMS based.

To solve cache invalidation, I need a JMS listener that intercepts the cache 'invalidate' messages generated by the Tridion Deployer. The listener connects to a JMS server that the Deployer is posting the notifications to. DD4T Java being a Spring MVC application, it makes only sense to use the in-built JMS listener container with all the goodies and handling of JMS communication already in it.

I used Bruce Snyder's blog post as inspiration to help me setup a DefaultMessageListenerContainer. Thank you Bruce, and thank you Spring, this was a breeze. My beans definition looks like this:

<bean id="cacheMessageListener" class="org.dd4t.core.caching.impl.CacheMessageListener"/>

<bean id="connectionFactory" class="org.apache.activemq.ActiveMQConnectionFactory">

    <property name="brokerURL" value="tcp://localhost:61616"/>

</bean>

<jms:listener-container container-type="default" destination-type="topic"

        connection-factory="connectionFactory" acknowledge="auto">

    <jms:listener destination="TridionCCS" ref="cacheMessageListener" method="onMessage"/>

</jms:listener-container>

Basically, a default listener container is declared and configured to listen to topics using the specified connection factory. The connection factory indicates an ActiveMQ JMS server is used and specifies its broker location. The listener container defines one listener bean, the CacheMessageListener and the name of the topic to listen to messages from.

A couple of things to note here:

• Tridion uses JMS topics to send/receive messages, rather than JMS queues. Hence, the attribute destination-type that specifies the usage of topic TridionCCS;
• The listener-container also supports an attribute concurrency. As per Spring documentation, when listening to 'topics', concurrency must remain 1, which is also the default;

The actual code I had to write was in the CacheMessageListener, which is an implementation of interface javax.jms.MessageListener. The method to implement is onMessage and it is called by the JMS listener container when a certain message arrives from the specified destination.

public class CacheMessageListener implements MessageListener {

    @Override

    public void onMessage(Message message) {

        CacheEvent event = getCachEvent(message);

        // ... invalidate cache

    }

    private CacheEvent getCachEvent(Message message) {

        CacheEvent event = null;

        if (message instanceof ObjectMessage) {

            ObjectMessage objectMessage = (ObjectMessage) message;

            Serializable serializable = objectMessage.getObject();

            if (serializable instanceof CacheEvent) {

                event = (CacheEvent) serializable;

            }

        }

        return event;

    }

}

The JMS message received is in my case an ActiveMQObjectMessage, because I'm using ActiveMQ JMS server. It embodies the actual message object, which is an instance of com.tridion.cache.CacheEvent.

The CacheEvent is a simple Java Bean, which encapsulates three properties: regionPath, key, and eventType. It is these properties, and namely the key property we are going to use to actually perform the invalidation of items in the cache.

But more about that, in my next blog post...