Caching

As of version 5.7, Trax distributes cache changes via JM. Tne web and server layers are in sync in a single server and across multiple servers (e.g. batch, GUI, etc.).

The underlying cache framework is EHCache and is configured in the trax-ehcache.xml file (one for config-war and one for config-ear). This file contains the default settings for all implicitly created caches and some explicitly defined caches. Note that if a cache is defined explicitly in these configuration files and doesn’t specify a cache listener for incoming events, it does not participate in the distributed cache game.

All Trax cache managers connect to a JMS topic to notify others of specific cache changes and to receive information of remote cache changes. When a specific cache is cleared (i.c. when the removeAll method is invoked on the underlying EHCache instance), a JMS message is published on the topic that contains the name of the cache and the operation that has been performed. This message is then picked up by the peer caches and they clear their local version of that specific cache. All individual changes to the caches are not replicated to minimize overhead.

Currently all known caches are listed in cache.properties (included in the framework jar). This is needed to make sure that all caches exist on all environments so the necessary events can be triggered.

CRUD listeners react on changes in the persistence layer. The ValueObjectCache and DecoratorCache implementations cache all instances of a model entity and are automatically cleared by a CRUD listener when their related entity changes.

The topic that is used is available in JNDI at “java:/jms/TraxCacheTopic” and is accessed via the ActiveMQ resource adapter.

Here is a link on how EHCache uses JMS to replicate caches: http://ehcache.org/documentation/2.6/replication/jms-replicated-caching.

In a multiple server setup make sure that:

1. a single ActiveMQ server is installed
2. all application servers point to the same ActiveMQ server