cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Unico Hommes <un...@hippo.nl>
Subject Re: EHDefaultStore
Date Thu, 02 Dec 2004 13:35:02 GMT

On 2-dec-04, at 13:13, Jon Evans wrote:

> 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.
>

EHDefaultStore is eternal by design. Having a store that would take 
care of expiration itself does not fit well with the way Cocoon uses 
and manages its stores. In order to open up the implementation to other 
uses than that of Cocoon it would be best to follow the same pattern as 
DefaultStore is doing. That is, move the current EHDefaultStore to 
AbstractEHStore and have EHDefaultStore extend AbstractEHStore and 
hard-code / overide some of the parameter settings.

> 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.
>

Yes, we need it. IIRC some settings can only be specified in the 
descriptor file. Most notably the filesystem location of the disk-based 
cache. If you look at the EHDefaultStore code you can see that it 
relies on the fact that disk based cache location is configured to be 
the java.io.tmpdir system property.

> 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.
>

Look at the implementation of CacheManager.create(1) the CacheManager 
is already a shared instance. Calling CacheManager.create() with a 
different config file after it has already been initialized previously 
has no effect. Another reason to not have the configuration file be 
configurable.


1. http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=107066391625123&w=2

--
Unico


Mime
View raw message