You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Antonio Gallardo <ag...@agssa.net> on 2005/05/30 08:27:19 UTC
[SUMMARY] Caching DynamicSelectionList
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.
Re: [SUMMARY] Caching DynamicSelectionList
Posted by Joerg Heinicke <jo...@gmx.de>.
Antonio Gallardo <agallardo <at> agssa.net> writes:
> > I don't think having a shorter cache period than a
> > form processing (as part of one request) makes no sense as it leads
> > to inconsistent forms when a selection list is reused.
>
> Please explain. More this. Are you telling a cache life shorter than a
> request, makes or not makes sense?
Makes no sense. But not a request, only the processing phase of one form to be
exact.
> Sorry, for the above question. Too much negation on the sentence got me
> confused.
I like it ;-)
> > Now I can think of optimizations of the above when you only use a
> > selection list (or the source it is based on to be exact) once in a
> > form: there is no need for buffering.
>
> Yep. I told that in one of my first mails. It can also be stated as:
> caching matter only inside a repeater.
No, different selection lists might be based on one source. They must be equal
though.
> > Can this be determined?
>
> Yep. If (the selection-list widget has not a repeater as ancestor) OR
> ((the selection list widget if has a repeater as ancestor) AND (the
> repeater has less than 2 rows)
No, see above (repeater is not sufficient). :-)
Joerg
Re: [SUMMARY] Caching DynamicSelectionList
Posted by Antonio Gallardo <ag...@agssa.net>.
On Jue, 2 de Junio de 2005, 2:50, Sylvain Wallez dijo:
> Antonio Gallardo wrote:
>>Are we going to deprecate @dynamic?
>
> Yes. Use of @dynamic should be logged as deprecated. Also, the default
> behavior should be changed to either cache="none" or cache="request",
> whereas today it's similar to cache="static".
Just committed:
Cforms block: Caching selection list for best performance inside
repeaters. Deprecate @dynamic in <fd:selection-list> in favor of @cache.
Posible @cache values are:
* static => equivalent to old @dynamic="false"
* none => equivalent to old @dynamic="true"
* request => is new, similar to cache="none", but caching the
selection list per request. Useful to improve performance inside
repeaters.
Defaults are the same as before.
- 0 -
Now looking forward, the next task is improve the SelectionLIst
performance, when it is created using:
<fd:on-value-changed>
<fd:javascript>
var value= ....
myWidget.setSelectionList("cocoon:/mySelectionList?id=" + value);
.....
</fd:javascript>
</fd:on-value-changed>
Thanks for all the help provided! ;-)
Best Regards,
Antonio Gallardo.
Re: [SUMMARY] Caching DynamicSelectionList
Posted by Sylvain Wallez <sy...@apache.org>.
Antonio Gallardo wrote:
>On Mar, 31 de Mayo de 2005, 16:26, Joerg Heinicke dijo:
>
>
>>Vadim's comments made me think again about the caching of selection
>>lists. And I don't think having a shorter cache period than a
>>form processing (as part of one request) makes no sense as it leads
>>to inconsistent forms when a selection list is reused.
>>
>>
>
>Please explain. More this. Are you telling a cache life shorter than a
>request, makes or not makes sense?
>
>Sorry, for the above question. Too much negation on the sentence got me
>confused.
>
>
>
>>Having this you *can* use time-based caching as you just
>>need to check the cache validity on first access to the source during
>>the form processing. During the form processing you always use the
>>same (buffered) selection list.
>>
>>
>
>
>
>>Now I can think of optimizations of the above when you only use a
>>selection list (or the source it is based on to be exact) once in a
>>form: there is no need for buffering.
>>
>>
>
>Yep. I told that in one of my first mails. It can also be stated as:
>caching matter only inside a repeater.
>
>
>
>>Can this be determined?
>>
>>
>
>Yep. If (the selection-list widget has not a repeater as ancestor) OR
>((the selection list widget if has a repeater as ancestor) AND (the
>repeater has less than 2 rows)
>
>
>
>>Now the other validity scopes. I do not have a real idea how to
>>configure it.
>>@cache="request|form|session|static"? (Is current "static" bound to form
>>
>>
>instance or even longer? If it is the first it will be the same like
>what I had in mind with "form").
>
>1. per request (I have this already implemented on my HD, including the
>lastest comments about how to implement it).
>
>2. Per form, What I understand here is to cache all the selection-list and
>use the cache until the form is finished.
>
>3.per session. Valid while the user is logged in. Refreshed on each new
>login.
>
>4.static. As it is implemented now.
>
>About 2 and 3. I believe there are some usecases for them. What I am not
>sure is if the time effort vs. gain is important enough to add more
>complexity. Maybe, yes, but I will be glad to see them first. And check if
>this is OK.
>
>
IMO the complexity is in setting up the cache mechanism. Adding new
scopes (i.e. cache durations) is then mostly a matter of finding the
right place to store the cached data.
>>Time based caching can be easily done on the pipeline as
>>we know or using the cached: pseudo protocol, but then you still
>>either have no buffered selection list sax events or you need
>>an object holding the buffer with the necessary lifetime.
>>
>>
>
>Currently, I only create the buffer if there is the corresponding flag. I
>don't think it can create problems for time based cache.
>
>BTW, I don't committed, because I want to know the final keywords for
>@cache.
>
We can start with static and request, and add other values later.
>Are we going to deprecate @dynamic?
>
>
Yes. Use of @dynamic should be logged as deprecated. Also, the default
behavior should be changed to either cache="none" or cache="request",
whereas today it's similar to cache="static".
Sylvain
--
Sylvain Wallez Anyware Technologies
http://apache.org/~sylvain http://anyware-tech.com
Apache Software Foundation Member Research & Technology Director
Re: [SUMMARY] Caching DynamicSelectionList
Posted by Antonio Gallardo <ag...@agssa.net>.
On Mar, 31 de Mayo de 2005, 16:26, Joerg Heinicke dijo:
> Vadim's comments made me think again about the caching of selection
> lists. And I don't think having a shorter cache period than a
> form processing (as part of one request) makes no sense as it leads
> to inconsistent forms when a selection list is reused.
Please explain. More this. Are you telling a cache life shorter than a
request, makes or not makes sense?
Sorry, for the above question. Too much negation on the sentence got me
confused.
> Having this you *can* use time-based caching as you just
> need to check the cache validity on first access to the source during
> the form processing. During the form processing you always use the
> same (buffered) selection list.
> Now I can think of optimizations of the above when you only use a
> selection list (or the source it is based on to be exact) once in a
> form: there is no need for buffering.
Yep. I told that in one of my first mails. It can also be stated as:
caching matter only inside a repeater.
> Can this be determined?
Yep. If (the selection-list widget has not a repeater as ancestor) OR
((the selection list widget if has a repeater as ancestor) AND (the
repeater has less than 2 rows)
> Now the other validity scopes. I do not have a real idea how to
> configure it.
> @cache="request|form|session|static"? (Is current "static" bound to form
instance or even longer? If it is the first it will be the same like
what I had in mind with "form").
1. per request (I have this already implemented on my HD, including the
lastest comments about how to implement it).
2. Per form, What I understand here is to cache all the selection-list and
use the cache until the form is finished.
3.per session. Valid while the user is logged in. Refreshed on each new
login.
4.static. As it is implemented now.
About 2 and 3. I believe there are some usecases for them. What I am not
sure is if the time effort vs. gain is important enough to add more
complexity. Maybe, yes, but I will be glad to see them first. And check if
this is OK.
> Time based caching can be easily done on the pipeline as
> we know or using the cached: pseudo protocol, but then you still
> either have no buffered selection list sax events or you need
> an object holding the buffer with the necessary lifetime.
Currently, I only create the buffer if there is the corresponding flag. I
don't think it can create problems for time based cache.
BTW, I don't committed, because I want to know the final keywords for
@cache. Are we going to deprecate @dynamic?
Best Regards,
Antonio Gallardo.
Re: [SUMMARY] Caching DynamicSelectionList
Posted by Joerg Heinicke <jo...@gmx.de>.
Vadim's comments made me think again about the caching of selection lists. And I
don't think having a shorter cache period than a form processing (as part of one
request) makes no sense as it leads to inconsistent forms when a selection list
is reused. Having this you *can* use time-based caching as you just need to
check the cache validity on first access to the source during the form
processing. During the form processing you always use the same (buffered)
selection list.
Now I can think of optimizations of the above when you only use a selection list
(or the source it is based on to be exact) once in a form: there is no need for
buffering. Can this be determined?
Now the other validity scopes. I do not have a real idea how to configure it.
@cache="request|form|session|static"? (Is current "static" bound to form
instance or even longer? If it is the first it will be the same like what I had
in mind with "form".) Time based caching can be easily done on the pipeline as
we know or using the cached: pseudo protocol, but then you still either have no
buffered selection list sax events or you need an object holding the buffer with
the necessary lifetime.
Joerg
Re: [SUMMARY] Caching DynamicSelectionList
Posted by Sylvain Wallez <sy...@apache.org>.
Antonio Gallardo wrote:
>On Lun, 30 de Mayo de 2005, 4:54, Sylvain Wallez dijo:
>
>
>>Antonio Gallardo wrote:
>>
>>
>>>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.
>>>
>>>
>>>
>>>
>>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
>>cache="static|request".
>>
>>
>
>IMHO in a DSL a "static cache" has no sense.
>
>
Yes it does!
Actually DSL is a wrong term as it's not a "dynamic selection list" but
a "selection list defined by a URL". And this URL can be a file, a
remote ftp resource, the contents of a blob, or whatever resource that
can be accessed with Cocoon protocols. Stating cache="static" means you
load it once when the form definition is parsed and don't reload it
later. This is exactly what currently happens with dynamic="false" (the
default): the URL is fetched and the selection list created once for
all, whatever protocol is used.
Lists defined by "cocoon:" are just a particular use case of the
selection list defined by a URL for which we are likely to want reload
to happen.
>Perhaps we can define:
>
>request-cache="yes|no" for DSL. And this is more explicit.
>
>I don't like this attribute is very implementation oriented. People will
>need to rewrite all the forms in order to take advantage of that. Well, it
>is very easy using jEdit...but... I think it is not too much dificult (and
>almost no time consuming) search ancestors looking for a Repeater.
>
>
They don't need to rewrite: handling of the "dynamic" attribute can stay
around for a while with the appropriate deprecation log.
And the attribute *has* to be implementation-oriented, as it is there to
provide more control over the behavior of the implementation.
>Perhaps better is: request-cache="auto|yes|no"
>
>When the user don't this attribute in definition.xml it means he want a
>SSL, right?
>
>Wich will be the default behavior using:
>
>myWidget.setSelectionList(...);
>
>Here we cannot define the cache.
>
>I thought we can create a new method:
>
>myWidget.setCachedSelectionList(...);
>
>The more I think about this, I am more thinking the best is to make this
>automatically and let cocoon decide when use the cache or not.
>
>Another question: How to access the request attributes from
>DynamicSelectionList.java without touching another file? I cannot see how
>to get the FormContext from the DSL code.
>
>
You can access the request from the Avalon context using ContextHelper,
and a SelectionListBuilder can be made contextualizable.
>BTW, The code is almost done.
>
>
Great!
Sylvain
--
Sylvain Wallez Anyware Technologies
http://apache.org/~sylvain http://anyware-tech.com
Apache Software Foundation Member Research & Technology Director
Re: [SUMMARY] Caching DynamicSelectionList
Posted by Antonio Gallardo <ag...@agssa.net>.
On Lun, 30 de Mayo de 2005, 4:54, Sylvain Wallez dijo:
> Antonio Gallardo wrote:
>>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.
>>
>>
>
> 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
> cache="static|request".
IMHO in a DSL a "static cache" has no sense.
Perhaps we can define:
request-cache="yes|no" for DSL. And this is more explicit.
I don't like this attribute is very implementation oriented. People will
need to rewrite all the forms in order to take advantage of that. Well, it
is very easy using jEdit...but... I think it is not too much dificult (and
almost no time consuming) search ancestors looking for a Repeater.
Perhaps better is: request-cache="auto|yes|no"
When the user don't this attribute in definition.xml it means he want a
SSL, right?
Wich will be the default behavior using:
myWidget.setSelectionList(...);
Here we cannot define the cache.
I thought we can create a new method:
myWidget.setCachedSelectionList(...);
The more I think about this, I am more thinking the best is to make this
automatically and let cocoon decide when use the cache or not.
Another question: How to access the request attributes from
DynamicSelectionList.java without touching another file? I cannot see how
to get the FormContext from the DSL code.
BTW, The code is almost done.
Best Regards,
Antonio Gallardo.
Re: [SUMMARY] Caching DynamicSelectionList
Posted by Sylvain Wallez <sy...@apache.org>.
Antonio Gallardo wrote:
>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.
>
>
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
cache="static|request".
>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.
>
>
Yup.
>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.
>
>
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
>handling.
>
>How this sound now?
>
>
Good :-)
Sylvain
--
Sylvain Wallez Anyware Technologies
http://apache.org/~sylvain http://anyware-tech.com
Apache Software Foundation Member Research & Technology Director
Re: [SUMMARY] Caching DynamicSelectionList
Posted by Antonio Gallardo <ag...@agssa.net>.
On Mar, 31 de Mayo de 2005, 8:55, Vadim Gritsenko dijo:
> Antonio Gallardo wrote:
>> On Mar, 31 de Mayo de 2005, 8:04, Vadim Gritsenko dijo:
>>
>>>Antonio Gallardo wrote:
>>>
>>>>THE SOLUTION
>>>
>>>...
>>>
>>>>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.
>>>
>>>Three questions:
>>>
>>> (1) What is cached? What is the structure of cached object.
>>
>>
>> We will cache a SaxBuffer of the selection-list.
>>
>>
>>> (2) WRT to (1), how to cache selection list for a longer time
>>> period than for single request? e.g., for (a) session
>>> duration, (b) for predefined time interval.
>>
>>
>> This was not considered. I think we should discuss this.
>>
>>
>>> (3) Why you do not cache output of the pipeline producing
>>> selection list?
>>
>>
>> Yep. We do that. See reply to (1).
>
> (1) was not question about pipeline but question about selection list
> caching
> which you were about to implement - and you had anwered it.
>
> (3) is my question why your pipeline producing selection list is currently
> not
> cacheable, as far as I understand, and why you do not want to try caching
> it.
> This question is *completely* not related to the selection lists at all.
Maybe. Even if the pipeline is cached, we need to resolve the source and
run the pipeline. This is the way the selection list is implemented now.
Why I don't want to cache the pipeline?
Suppose you have a selection-list in a repeater and in the middle of row
generation the cache expires. Before the cache expires, there where done
some changes in the database, then there is an inconsistency (at least
from the user POV). The same repeater in diferents rows will have diferent
items. It will trig a lot of support calls, between other troubles.
Best Regards,
Antonio Gallardo.
Re: [SUMMARY] Caching DynamicSelectionList
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Antonio Gallardo wrote:
> On Mar, 31 de Mayo de 2005, 8:04, Vadim Gritsenko dijo:
>
>>Antonio Gallardo wrote:
>>
>>>THE SOLUTION
>>
>>...
>>
>>>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.
>>
>>Three questions:
>>
>> (1) What is cached? What is the structure of cached object.
>
>
> We will cache a SaxBuffer of the selection-list.
>
>
>> (2) WRT to (1), how to cache selection list for a longer time
>> period than for single request? e.g., for (a) session
>> duration, (b) for predefined time interval.
>
>
> This was not considered. I think we should discuss this.
>
>
>> (3) Why you do not cache output of the pipeline producing
>> selection list?
>
>
> Yep. We do that. See reply to (1).
(1) was not question about pipeline but question about selection list caching
which you were about to implement - and you had anwered it.
(3) is my question why your pipeline producing selection list is currently not
cacheable, as far as I understand, and why you do not want to try caching it.
This question is *completely* not related to the selection lists at all.
Vadim
Re: [SUMMARY] Caching DynamicSelectionList
Posted by Antonio Gallardo <ag...@agssa.net>.
On Mar, 31 de Mayo de 2005, 8:04, Vadim Gritsenko dijo:
> Antonio Gallardo wrote:
>> THE SOLUTION
> ...
>> 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.
>
> Three questions:
>
> (1) What is cached? What is the structure of cached object.
We will cache a SaxBuffer of the selection-list.
> (2) WRT to (1), how to cache selection list for a longer time
> period than for single request? e.g., for (a) session
> duration, (b) for predefined time interval.
This was not considered. I think we should discuss this.
> (3) Why you do not cache output of the pipeline producing
> selection list?
Yep. We do that. See reply to (1).
> I'd suggest trying (3) first before considering any other changes.
>
> There is NO db application where data could not be cached for some time
> period.
> That's in the nature of the database: as soon as you read up your
> selection
> list, it is already stale (there is no guarantee that somebody had not
> changed
> it already), so why not cache it for a bit longer?
Because in the next request we want to check we are using the lastest
changes. In some cases is not a good idea to cache SL longer than in the
same request. I already saw a big performance improvement inside repeaters
and I will be glad to implement this first before do deeper changes.
> And as far as caching goes, there are more usecases for the caching for
> session duration or fixed time interval, IMHO, than for request duration.
Dunno if per session is a good idea. While we know there are some SL that
does not change too much. When a change is posted, the user expect to see
the change in the next request. This is how the things works in most
applications today.
> So caching, if implemented at all, should be flexible enough to
> accomodate different use cases:
> shared lists (with timed expiration),
Easily implented with pipeline cocoon cache. Personally I don't like this.
Joerg pointed out this can have inconsistencies in a form.
> per-user lists (cached for session duration, or with time expiration) -
and,
> per-request lists can be a (rarely used ;-)) option as well.
This one is what I need to use. I am implementing it right now. ;-)
Best Regards,
Antonio Gallardo.
Re: [SUMMARY] Caching DynamicSelectionList
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Antonio Gallardo wrote:
> THE SOLUTION
...
> 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.
Three questions:
(1) What is cached? What is the structure of cached object.
(2) WRT to (1), how to cache selection list for a longer time
period than for single request? e.g., for (a) session
duration, (b) for predefined time interval.
(3) Why you do not cache output of the pipeline producing
selection list?
I'd suggest trying (3) first before considering any other changes.
There is NO db application where data could not be cached for some time period.
That's in the nature of the database: as soon as you read up your selection
list, it is already stale (there is no guarantee that somebody had not changed
it already), so why not cache it for a bit longer?
And as far as caching goes, there are more usecases for the caching for session
duration or fixed time interval, IMHO, than for request duration. So caching, if
implemented at all, should be flexible enough to accomodate different use cases:
shared lists (with timed expiration), per-user lists (cached for session
duration, or with time expiration) - and, per-request lists can be a (rarely
used ;-)) option as well.
Vadim