cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: [SUMMARY] Caching DynamicSelectionList
Date Mon, 30 May 2005 09:54:52 GMT
Antonio Gallardo wrote:

>Here is a summary of what was dicussed to understand what we are trying to
>do. I hope this will help others that were not following the discussion to
>understand this proposal that changes the current SelectionList
>Currently we are caching only Static SelectionList (SSL). The cache is
>created on form building time and cached forever. AFAIK, there is no
>chance to reload it with new values.
>The Dynamic SelectionList (DSL) creates a SelectionList from a given
>source (can be a pipeline). The source is readed each time the DSL is
>generated. There is no cache at all.
>We need to improve cforms performance.
>The form generation time increase dramatically when we have DSLs in a
>repeater. We observed the most time is dedicated to generate this DSLs.
>The DSL generation time almost define the total form generation time.
>In DB intensive apps, this makes cforms pretty slow inside repeaters.
>The situation is worse when we define more than one DSL per repeater row.
>We found is posible to improve DSL performance by caching the DSL item
>data list once per request. The DSL remains dynamic per request.
>Caching DSL will not affect the current behaviour. The time for DSL
>generation will be reduced substancially.
>Our proposed solution is add a new user defined attribute, called "cache"
>in <fd:selection-list>. This way the cform user can decide when he wants
>to use a cached DSL or not. For SSL this attribute has no meaning.
>Posible values for @cache:
>true  - Cache SL content per request.
>false - No Cache SL content.
>default value: false.

I'm wondering about the "cache" name which says nothing about the cache 
duration, which is here the request. If we consider the behaviour of 
dynamic="false", we can consider it as equivalent to cache="static" 
(i.e. load once and never refresh).

So IMO we should be deprecating dynamic="true" in favor of 

>1- The new @cache attrribute wil be readed at form build time.
>2- The cache will be stored inside request attributes with a unique name.
>This way we make sure this short-time cached will be droped right after
>the request.
>3-To generate the unique name we will use:
>   new java.rmi.server.UID().toString()
>4.When generating the SAX fragment, if the attribute is empty, then the
>pipeline is called and cached on the fly. If the attribute exists it will
>be used immediately.


>If the user does not define @cache -> cforms must automatically decide to
>cache or not while building the form model. Whe have enough info in form
>definition to do that. Investigate the posible cases and set the attribute
>as needed.

Thinking further, we have some sensible heuristics to automatically 
enable caching: if a widget definition has a selection list _and_ one of 
its ancestors (not only the parent) is a repeater definition, then we 
can enable caching automatically.

Now this can be implemented later.

>Remove the cache attribute? If cocoon will auto decide when use cache,
>this attribute can stay to force a user decision when needed a special
>How this sound now?

Good :-)


Sylvain Wallez                        Anyware Technologies  
Apache Software Foundation Member     Research & Technology Director

View raw message