cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Antonio Gallardo" <agalla...@agssa.net>
Subject [SUMMARY] Caching DynamicSelectionList
Date Mon, 30 May 2005 06:27:19 GMT
Hi:

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
implementation.

CURRENT SITUATION
=================
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.

THE NEED
========

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.

THE SOLUTION
============

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.

ARCHITECTURE
============

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.


FUTURE ENHANCEMENTS
===================

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.

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
handling.

How this sound now?

Best Regards,

Antonio Gallardo.

Mime
View raw message