Nope. It's dangerous stuff that should be used with care.
On Tue, Mar 18, 2008 at 10:01 AM, Tobias Marx <[EMAIL PROTECTED]> wrote:
> Wouldn't it be useful to make the @Cache annotation the default annotation
> for all methods?
>
> I can not imagine a case where it would make sense that during the rendering
> of a page returns different results...
>
> -------- Original-Nachricht --------
> > Datum: Tue, 18 Mar 2008 11:53:09 -0500
> > Von: "Adam Zimowski" <[EMAIL PROTECTED]>
>
> > An: "Tapestry users" <users@tapestry.apache.org>
> > Betreff: Re: @Cached and caching in general
>
>
>
> > @Cache works on per request basis, so that anything you return from a
> > method which has @Cache annotation will get actually "built" or
> > "retrieved" only once - but only once per http request. So if you're
> > building an expensive HTML fragment:
> >
> > @Cached
> > public String buildExpensiveHtmlFragment() {
> > //.........
> > }
> >
> > during a request of a single thread you can call
> > buildExpensiveHtmlFragment() as many times as you want with a full
> > confidence that the work to build it would be performed only once.
> > When you refresh the page, the build will be invoked once again (but
> > once only).
> >
> > -adam
> >
> > On Tue, Mar 18, 2008 at 11:44 AM, 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]
>
>
--
Howard M. Lewis Ship
Creator Apache Tapestry and Apache HiveMind
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
