Confluence Docs 3.0 : Confluence Caching Architecture This page last changed on Aug 20, 2009 by ggaskell. The cache service provides centralised management of in-memory data caching within the Confluence application. Depending on which edition of Confluence you are running, the cache service may be backed by ehcache (standard edition) or Oracle Coherence (clustered edition). Because of this, it is even more important than normal that you only code to the interfaces provided by Confluence, and do not rely on any of the concrete implementation classes. For more information about standard and clustered editions of Confluence, please refer to the Coherence license changes document. ## The CacheManager The `cacheManager` bean in the Confluence Spring application context implements two interfaces: `CacheFactory` and `CacheManager`. The only method on the manager you need to worry about (unless you are maintaining the caching system as a whole) is `CacheFactory#getCache(java.lang.String name)`. This method will return a `Cache`. To prevent cache name clashes, we suggest using the same reverse domain name syntax for naming caches as you would for Java class names or plugin keys. You can provide a "friendly name" for the cache management UI by providing an I18N key: `cache.name.[cache name]`. ## Unflushable Caches A small number of caches are configured to not be flushed by `CacheManager.flushCaches()`. These cache names are defined by the `nonFlushableCaches` bean in `cacheServiceContext.xml`. There is currently no plan to broaden this mechanism to allow plugin-specified caches to opt in to not being flushed. ## Differences Between Editions The differences between the standard and clustered editions of Confluence are: Standard edition packages the `confluence-cache-ehcache` module Clustered edition packages the `confluence-cache-coherence` module Both of these modules are contained in the `cache` subdirectory of the main Confluence source tree. Having both or neither of confluence-cache-ehcache and confluence-cache-coherence in the Confluence classpath will cause the system not to run. ## Implementation There are a couple of different places the caching subsystem hooks into the rest of Confluence. #### Bootstrapping During bootstrapping, Confluence will try to load `/bootstrapCacheContext.xml` into the Spring context. This file will be found in one of the cache implementation jars. This context file is responsible for providing an implementation of the `ClusterManager`, `ClusterConfigurationHelper` and `HibernateCacheFactory`. You can tell which edition of Confluence you are running by calling `ClusterManager#isClusterSupported`. This will return true in clustered editions, false otherwise. #### Hibernate Hibernate is configured to use the `ConfluenceCacheProvider` as its cache provider. This provider delegates to the `HibernateCacheFactory` (as defined in the bootstrap context above) to instantiate the correct cache implementation depending on the Confluence edition being run. #### The Cache Manager During main application startup, Confluence will try to load `/cacheProviderContext.xml` into the Spring context. This file will also be found in one of the cache implementation jars and is responsible for instantiating the correct implementation of the CacheManager. #### The Cache Management UI The user interface (and backing implementation) for viewing, flushing and adjusting the sizes of caches are implemented as plugins within each of the cache implementation jars. ## Gotchas ehcache will log a warning if a cache is created for which it does not have an explicit configuration in `ehcache.xml`. We should ensure that there are no such warnings before releasing a new version of Confluence.

Document generated by Confluence on Nov 05, 2009 23:34