cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jorg Heymans ...@domek.be>
Subject Re: EHDefaultStore
Date Thu, 02 Dec 2004 13:38:47 GMT
Hi Jon,

A few loose thoughts here, i just dealt with similar issues last week.


Jon Evans wrote:
> 
> 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.
I'm not sure on the exact role of EHDefaultStore (allright I didn't know 
it even existed).

I am using my "own" cachemanager created as follows

CacheManager.create(new FileInputStream(new File( 
"/WEB-INF/classes/ehcache.xml")));

In this file i configure my caches and also provide a default cache.
I then create my configured caches with 
manager.getCache("myconfiguredcache1")

(a side effect of this is that Cocoon dumps it's ehcache in the dir 
configured in my ehcache.xml). This means it's using the default cache 
which is a bad thing IMHO.

> 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.
true, just use the default factory method for creating the cache.
> 
> 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.
Doesn't ehcache have finalizer hooks on the cachemanager ? Or is cocoon 
shutting the cachemanager down properly? Reason i'm asking is that my 
cache gets shutdown properly even when I don't shutdown the manager.


How about making cocoon use an explicit named cache instead of the 
default one ?

Regards,
Jorg


Mime
View raw message