Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Message-ID: <40488FEC.9070908@leverageweb.com>
Date: Fri, 05 Mar 2004 09:34:20 -0500
From: Geoff Howard <cocoon@leverageweb.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
 rv:1.6) Gecko/20040113
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: Turning off default MRU store
References: <C726734B5ACA2445B2BB93E87ADD5033AF3A44@akxch03.tvnzad.tvnz.co.n
	z> <4047ED4E.5020007@hippo.nl> <4047EED3.6020307@hippo.nl>
 <40488750.9010304@apache.org> <40488B7D.6080504@hippo.nl>
In-Reply-To: <40488B7D.6080504@hippo.nl>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Unico Hommes wrote:

> Sylvain Wallez wrote:
>
>> Unico Hommes wrote:
>>
>>>
>>> Unico Hommes wrote:
>>>
>>>>
>>>>
>>>> Corin Moss wrote:
>>>>
>>>>> Hi Guys,
>>>>>
>>>>> I might be getting ahead of myself a bit here, but I'm going to 
>>>>> try and turn off the default MRU store, in favour of the JCS based 
>>>>> persistent store.  I'd like to try some tests on performance 
>>>>> without the default MRU - has anyone else tried anything similar? 
>>>>> I've simply set the core store's role to point to the JCS store 
>>>>> implementation.
>>>>>
>>>>
>>>> I guess I already got ahead of you when I renamed 
>>>> JCSPersistentStore JCSStore just now :-) (And merged it with the 
>>>> AbstractJCSStore BTW). It seems to me that JCS is both and it could 
>>>> replace all three stores: DefaultStore, TransientStore and 
>>>> PersistentStore.
>>>>
>>>
>>> I have to add that this is not the whole story. We do actually need 
>>> to distinguish between persistent and transient storage. Some 
>>> components explicitly want to persist some data instead of just 
>>> cache it for speed. But as far as caching is concerned I think it we 
>>> can leave it completely up to JCS.
>>
>>
>>
>>
>> Some components are explicitely using the transient-store to keep 
>> data that shouldn't (or cannot) be serialized. But AFAIK, no 
>> component directly uses the persistent-store except the store itself.
>>
>
> To my knowlegde there is one in eventcache block that uses the 
> PersistentStore to persist some info it needs to recover upon next 
> startup.
>
> It does not look to me as though JCS would fit the PersistentStore 
> role very well. I was thinking that perhaps. We could have JCSStore as 
> a replacement for TransientStore and Store roles and use 
> FilesystemStore for the PersistentStore role.


Wait a minute.  The original issue that brought JCS to the front as that 
the persistent store was broken and had license problems.  Are you 
saying that JCS isn't a good candidate for persisting the cached info to 
disk, or that the fact that it by default has an MRU memory front-end 
makes it not map directly to persistent-store role cleanly?

The use of persistent store in eventcache shouldn't be a problem with 
JCS as long as at shutdown, it persists everything it has in its MRU if 
it hasn't already.  If there is some problem it would be much better to 
just go back to the old serializing persistence for the event cache data 
because the only benefit to putting it in the store is that you more or 
less guaranteed that the events and cached responses would be kept together.

Geoff

>> So if the JCSStore includes a MRU-like memory front-end, it can 
>> simply replace the <store> component in cocoon.xconf.
>>
> My thoughts exactly