cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Antonio Gallardo" <agalla...@agssa.net>
Subject Re: Turning off default MRU store
Date Sat, 06 Mar 2004 09:54:41 GMT
Unico Hommes dijo:
> Geoff Howard wrote:
>
>> 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?
>>
> IIUC, JCS will always use a memory store in front yes. And it suggests
> on the JCS website that the persistence process is not very reliable:
>
> from http://jakarta.apache.org/turbine/jcs/IndexedDiskAuxCache.html :
>
> "When the disk cache is properly shutdown, the memory index is written
> to disk and the value file is defragmented. When the cache starts up,
> the disk cache can be configured to read or delete the index file. This
> provides an unreliable persistence mechanism."
>
>> 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.
>
>
> Yes, giving up that feature would be too bad.

Why?

If this is a "must needed feature" we can collaborate with the JCS team to
extend the work.

WDYT?

Best Regards,

Antonio Gallardo.


Mime
View raw message