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 Fri, 03 Dec 2004 12:45:13 GMT

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


Mime
View raw message