On 3-dec-04, at 13:27, Jon Evans wrote:
Hi Jorg,
On 2 Dec 2004, at 13:38, Jorg Heymans wrote:
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.
I've just checked out the ehcache source and confirmed what Unico said
in his reply: CacheManager is a singleton, so whichever component
starts up first (yours or EHDefaultCache) will configure the cache
manager. The second one to start up will just end up using the
existing instance, it won't be reconfigured. I'm sure this will work
fine 90% of the time, but I bet it would be hard to track down the
reason why it's suddenly ignoring changes you've made in your config
file (i.e. it already read the other one).
This is another reason why I think we need a system-wide ehcache
component, which is used by EHDefaultCache and any other instances
needed by specific applications...
I don't understand. What is wrong with the Store interface?
--
Unico
