cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jon Evans <jon.ev...@misgl.com>
Subject EHDefaultStore
Date Thu, 02 Dec 2004 12:13:19 GMT
Hi,

I needed a cache for part of my webapp.  Basically I can look up lists 
of things, based on a number of parameters.  I put all the parameters 
into a Serializable class which becomes the key.  If it isn't in the 
cache then I create a new object using a stored procedure and add it to 
the cache.  The stored procedure takes about 500ms, hence the need for 
the cache.

I had to create my own "version" of EHDefaultStore, specific to my app, 
because I didn't want an eternal cache.  I expire items after 5 minutes 
so that a db hit is forced (in case the data has been updated).  
Although EHDefaultStore takes many config parameters, it doesn't have 
eternal, timeToLive or timeToIdle, and is hard coded to always create 
an eternal cache.

My questions:

1) Any reason why those parameters can't be added?  Then I could have 
just configured my own instance in cocoon.xconf with a different role 
name to the default.

2) EHDefaultStore configures a CacheManager from an xml file, but then 
creates the Cache object itself using the long Cache() constructor.
 From my understanding of the EHCache docs, the xml file is used to set 
the defaults for if a Cache object is created by the CacheManager 
itself, which isn't being done in EHDefaultStore.
We might just as well use

CacheManager cacheManager = CacheManager.create(); // or getInstance()

even if the values in ehcache.xml are changed, it will make no 
difference because each Cache is programatically created using specific 
values for each property.  So we don't need it.

3) a CacheManager can manage more than one Cache, yet we create one per 
instance of EHDefaultStore.
OK, at the moment there is only one instance of EHDefaultStore (I 
think?), but if it's made more generic (see 1) then there could be 
more.  We could have a static CacheManager shared between them all.
This does however mean that we'd need an instance count so that the 
last instance could call cacheManager.shutdown() (and the first client 
would call create()).  But then we already do have an instance count 
which is used in EHDefaultStore to generate a new name each time the 
constructor is called.

Shall I submit a patch adding any of the above?

Jon


Mime
View raw message