cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jon Evans <jon.ev...@misgl.com>
Subject Re: EHDefaultStore
Date Fri, 03 Dec 2004 12:12:48 GMT
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...) :-)

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

Thanks,

Jon


Mime
View raw message