Or, you could take the approach that the OS is responsible for caching things on a local storage
device - then go ahead and code as if you have unlimited memory.
Chris Howe wrote:
Perhaps, instead of output caching to memory, output to a "temporary"
contentId and store the output to disk or to xml database?
--- BJ Freeman <[EMAIL PROTECTED]> wrote:
seems that the processing of the key would take up a lot of memory
and
time to process, assuming that 90% of the widgets were cached.
Jacopo Cappellato sent the following on 7/17/2007 8:32 AM:
Hi all,
I'd like to discuss with you all about the idea of implementing
screen
widget output caching.
Goal: minimize the db/service hits for rather static screens (for
example a category or product detail screen in the ecommerce); this
could be done by implementing screen widget output caching that
prevents
the screen widget actions (and possibly ftl) from running
Draft/proposal for implementation:
a) add new attributes in the screen definition for cache settings
(e.g.
cache="true|false" etc...)
b) the cache key can be derived from the screen name and the
"parameters" map (the output UtilHttp.getCombinedMap(...)) that
represents the input context for screens
c) associated to the cache key we will cache the final output of
the
screen (html code or xsl-fo code...)
d) if the cache is enabled for a given screen, the input
"parameters"
map is used as a key for the cache system, if no value is found,
then
the screen (actions + froms + ftl templates) is run as usual and
the
output is rendered and stored in the cache (with key screen name +
"parameters"); if the value is found, then the output is retrieved
from
memory and sent to the user (no actions and ftl are executed)
A different option would be that of storing the output context in
the
cache and serve it to the ftl (instead of storing the output
html/xsl-fo).
I'd love to get your feedback about this, ideas/concerns,
Jacopo
