Ok. Thanks...this is what I wanted to know. What about an annotation for "components"/"pages ?
@CachedOutput (time=3600) In this case a "component" or "page" would not render itself every time but cache its output to the filesystem (a cache directory). Every hour it would re-generate/refresh its output and this way save lots of performance..... -------- Original-Nachricht -------- > Datum: Tue, 18 Mar 2008 17:52:11 +0100 > Von: "Davor Hrg" <[EMAIL PROTECTED]> > An: "Tapestry users" <users@tapestry.apache.org> > Betreff: Re: @Cached and caching in general > @Cached is an annotation > that caches method call result per request. > so while page is rendering if multiple pieces of template > require that property it gets called only once... > > Davor Hrg > > On Tue, Mar 18, 2008 at 5:44 PM, Tobias Marx <[EMAIL PROTECTED]> wrote: > > I have not used T5 yet, but would @Cached use the file system for > caching HTML fragments similiar to caching mechanisms in some php frameworks? > > > > Or is this a pure memory-based cache? > > > > I am thinking about migrating an old PHP application to T5 - it has > really a lot of traffic and any users are logged in at the same time. > > > > It is quite a low-level application that is still quite fast due to > cron jobs in the background that generate HTML fragments that are included to > reduce the database-query bottleneck (e.g. grouping/ordering and sorting of > huge tables). > > > > Somehow I don't trust Hibernate for high-performance database queries > on huge tables .... as I think if tables are huge and many people access it, > it will always lead to problems...no matter how good the queries are and > how well you have splitted the data across several tables. > > > > So I think the best solution is always to generate HTML fragments in > the background that take a long time and simple "include" them....this is > even quicker then parsing templates when the data is cached. So you save the > time necessary for querying the database plus the time necessary for > processing the templates that are involved. > > > > Currently the setup on this application uses one-way database > replication and the cron jobs access the the huge data table on the replicated > database and generate those HTML fragments without disturbing the > web-applications performance. So the main application simply includes those > HTML > fragments within milliseconds. > > > > But maybe the T5 caching mechanism would make all of those low-level > tricks redundant? > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
