On 3-dec-04, at 13:12, Jon Evans wrote:
Hi Unico,
On 2 Dec 2004, at 13:35, Unico Hommes wrote:
On 2-dec-04, at 13:13, Jon Evans wrote:
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.
Sounds like a good idea. Shall I do that & submit the patch? (stupid question...) :-)
Yes please :-)
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.
OK. Incidentally, the code also includes:
System.setProperty("java.io.tmpdir", directoryPath);
is that a good idea? Any component starting after EHDefaultStore would see that new value for tmpdir, which could be different to the one set when the JVM started up. I don't think it could cause problems but you could potentially end up with temp files in two different places. Or have I misread it again?
No, you are absolutely right. This is a hazardous situation. Unfortunately, I don't think there is an easy way around this. The only thing I can think of ATM is to manipulate the configuration file's input stream to insert the right value.
-- Unico
