cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vadim Gritsenko <va...@reverycodes.com>
Subject Re: my doubts about the current CocoonStoreJanitor/StoreJanitorImpl
Date Tue, 18 Jul 2006 13:00:34 GMT
Ard Schrijvers wrote:
>> Ard Schrijvers wrote:
>>
>> I can suggest you two easy enhancements to improve the situation.
>>
>> 1. Stores should have configuration which specifies whether 
>> store should 
>> register itself with the StoreJanitor or not. Default 
>> transient store can be 
>> configured to *not* register with janitor, so that all your 
>> XSLTs stay in memory.
> 
> StatusGenerator can't give the status of stores not registered to the StoreJanitor. I
would rather still register them to the StoreJanitor, but configure them not to be "cleared"
by the StoreJanitor
> 
>> 2. StoreJanitor can have another eviction algorithm, namely, 
>> it should have an 
>> option to remove configured % of entries from *all* 
>> registered stores. So that 
>> it empties some part of all stores on each eviction run. It 
>> would make system 
>> behavior more even and stable, in situations were there are 
>> multiple stores with 
>> varying object sizes.
> 
> This in combination with (1) would then change into removing entries from *all stores
configured to be clearable by the StoreJanitor*. Rest seems fine to me

Right, this will achieve the same effect.

<snip/>

>>> So, in the StoreJanitor, I check now wether the store is 
>> instanceof EHDefaultStore,
>>
>> That's a really bad idea, in and by itself. Never rely on concrete 
>> implementations, always work against contracts (interfaces).
> 
> Ok. I try and see if there is another way to get this in. I still have to do the following
changes then
> 
> 1) StoreJanitor to only free cache/memory from stores configured to
> 2) Change the EHDefaultStore the "public int size()"  to return the memoryStoreSize()
> 3) Change the free() in EHDefaultStore according to the correct eviction policy. This
might need changes in the ehcache. 
> 
> I think this meets your requirements as well, right?

Looks good.

Vadim

Mime
View raw message