cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Peter Wyngaard " <>
Subject Is EHDefaultStore using ehcache.xml?
Date Thu, 10 Jan 2008 02:47:12 GMT
I think the answer is "no", and here's why:


I am using ExpiresCachingProcessingPipeline for an internal-only
pipeline that provides read-only access to a set of objects from our
database.  Many of the SQL Transformer queries are rather expensive,
hence the caching.


One of the things I wanted to spike was the concept of creating a
persistent ehcache file that could be built and used on a laptop in
situations where access to our database was either too slow to be
practical, or simple impossible.  At first glance, it looked like Cocoon
2.2 was going to make this easy, as I could create a custom ehcache.xml
file in, do something to prime
the cache, then I'd have a couple of portable ehcache flatfiles with a
subset of our database I could carry around on a laptop.


Ran into a few roadblocks.  One I'll mention here, and one in a separate


First, I'm not sure how EHDefaultStore is supposed to be configured.  On
the one hand, there are plenty of references (on the mailing list, in
documentation, and in the source code) to creating a custom ehcache.xml
file.  However, at line 383 of EHDefaultStore (cocoon/trunk), new caches
are created using EHDefaultStore instance variables.  These instance
variables are not being set from ehcache.xml, but rather via a separate
mechanism.  This means that my ExpiresCachingProcessingPipeline cache
will never use the ehcache.xml file parameters.


The EHDefaultStore bean is created by Spring in
cocoon-store-impl-ehcache.xml, and named
"".  The bean is created with the
following properties:


    <property name="maxMemObjects"

    <property name="useCacheDirectory"

    <property name="settings"


And those two variables come from, and are
set to:


by default.


So my questions:


* Am I supposed to create my own custom cocoon-store-impl-ehcache.xml
and file, and set all the various ehcache
parameters that way?


* Or, should EHDefaultStore be modified to allow the ehcache
CacheManager to create caches using the defaults it reads from


Even thought it meant modifying my working copy of cocoon/trunk, I opted
for the latter because it seemed like the better solution.  This
involved the following patch to


My question:  what is the correct solution?






a  (revision 610650)

a  (working copy)

@@ -380,22 +380,8 @@

         // read configuration - we have to replace the diskstorepath in
the configuration

         // as the diskStorePath argument of the Cache constructor is
ignored and set by the

         // CacheManager! (see bug COCOON-1927)

-        this.cache = new Cache(

-                        this.cacheName,

-                        this.maxMemObjects,

-                        this.memoryStoreEvictionPolicy,

-                        this.overflowToDisk,

-                        this.diskStorePath,

-                        this.eternal,

-                        this.timeToLiveSeconds,

-                        this.timeToIdleSeconds,

-                        this.diskPersistent,

-                        this.diskExpiryThreadIntervalSeconds,

-                        this.registeredEventListeners,

-                        this.bootstrapCacheLoader,

-                        this.maxDiskObjects);


-        this.cacheManager.addCache(this.cache);

+        this.cacheManager.addCache(this.cacheName);

+        this.cache = this.cacheManager.getCache(this.cacheName);

         if (this.storeJanitor != null) {




View raw message