cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Upayavira ...@upaya.co.uk>
Subject Re: [vote] Reschedule the release
Date Sat, 15 May 2004 07:46:12 GMT
Ugo Cei wrote:

> Il giorno 14/mag/04, alle 19:26, Antonio Gallardo ha scritto:
>
>> The JCS goes beyond simply caching objects in memory. It provides 
>> several
>> important features, necessary for any Enterprise level caching system,
>> features include Memory management, disk overflow, element grouping, 
>> quick
>> nested categorical removal, data expiration, extensible framework, fully
>> configurable runtime parameters, remote synchronization, remote store
>> recovery, non-blocking "zombie" pattern, optional lateral 
>> distribution of
>> elements, remote server clustering and failover. These features 
>> provide a
>> framework with no point of failure, allowing for full session failover
>> including session data across up to 256 servers.
>>
>> That is what we are looking for? :-D
>
>
> Frankly, no. At least, not in most applications. We already have too 
> much complexity in Cocoon, too many "configurable runtime parameters".

I have been looking for this functionality for a long time (persisting 
store to disc on shutdown), in a version that is faster than Jisp.

Basically, a servlet environment, restarts are uncommon. But with the 
CLI/bean, it happens every time it is run. With a store that quickly 
persists to disc, it will be possible to make it check the store before 
actually generating a page, and thus will be able to offer a speed 
improvement over the existing version.

I had this working a while ago with Jisp, but it was no faster than 
generating the pages themselves. With something other than Jisp, I 
suspect we could get  a worthwhile performance improvement.

Regards, Upayavira



Mime
View raw message