cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: Fixing store design (long) (was Re: CocoonForms server sizing?)
Date Sat, 06 Dec 2003 21:48:28 GMT
Carsten Ziegeler wrote:

>Sylvain Wallez wrote:
>>Clarify the store semantics
>>As we've seen below, the Store interface provides 3 roles: Store.ROLE, Store.TRANSIENT_STORE
and Store.PERSISTANT_STORE. But the problem is that PERSISTANT is defined as equal to ROLE
and we actually only have two real roles.
>>I propose to clearly distinguish the 3 roles and the associtated semantics:
>>- Store.ROLE is the "general-purpose" store. A component that doesn't care if the
cache is transient or persistent should use this one. Being general-purpose, it should be
efficient but also swap old objects to persistent storage.
>>- Store.TRANSIENT_STORE should be used to keep objects that aren't serializable but
should be kept in memory as far as possible. The flush strategy of this store should not be
mixed with a limited-size MRU policy of a persistent store front-end.
>>- Store.PERSISTANT_STORE should be, as its name implies, only persistant, with no
memory front-end or whatsoever.
>This was the basic idea of the three different roles, unfortunately due to lazyness :)
Store.ROLE and Store.PERSISTANT_STORE were made equal.

Mmmh... We currently have:
wich should be:
    String PERSISTENT_STORE = ROLE + "/PersitentStore";

A 20-character lazyness :-/

>So, big +1.
>>Redefine Cocoon stores
>One point about stores and caching. The cache is currently configurable which store it
uses. So, the cache can be configured to use the Store, the persistent store, the transient
store or the send-everything-per-email-to-admin-store. This allows to fine tune your caching;
perhaps some pipelines want to use the transient store, some the persistent, some an own one

Yep, but the current default is Store.TRANSIENT_STORE store, and I want 
to change this to "normal" Store.ROLE. This allows to have an adequate 
behaviour without having to explicitely declare the cache in cocoon.xconf.

This is a subject which is itching me badly: cocoon.xconf is way too 
big. We should remove every component definition that has the default 
built-in values (eventually leave them as comment) to simplify this 
frightening configuration file. The same applies to web.xml.


Sylvain Wallez                                  Anyware Technologies 
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance  -

View raw message