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
