I'm interested in the one for T5 :) if you are not allowed to share source, maybe few hints how to make it
Davor Hrg On Tue, Mar 18, 2008 at 7:22 PM, Fernando Padilla <[EMAIL PROTECTED]> wrote: > We have a component that we call "Buffer" :) it takes a timeout, > optional cachekey, and optional lastmodified (to tell you) > > We have it for Tap4 and Tap5, if anyone really wants it, I bet I can > liberate it.. you would just have to change the cache hooks to use > whatever cache you want to use... > > The easiest way to add caching to the app. :) > > > > Martin Kersten wrote: > > @Chached is only used during a single page rendering cycle. It would not > > apply to your situation. (as far as I know) > > > > Source: > > http://sqllyw.wordpress.com/2008/03/15/new-features-in-tapestry-5011/ > > > > Your scenario would be implementable using your own component. > > The component would represent a fragment and read the file (even > > use a inmemory cache strategy (soft/weakreferences)) and write > > the ouput directly to stream (or actually the dom tree of your > > document being returned). > > > > Using your own solution enables you to mimic the behavior you talk about. > > Another idea would to write / cache only datas needed to render the tables > > (e.g. cache only content not markup). Never the less I am in doupt, > > if such a solution is necessary (dynamically cache results of > > database queries in memory or on disk). > > > > So after all you might want to port your application. As always use > > the simpliest solution first. So database queries without any caches. > > Once you see any problems (performance is below required) just go for > > optimization. Since you have a fallback solution at hand (cron-jobs + > > disk fragments) you are at the safe side. But I am in doupt if you > > really need the markup being cached. Caching the database results > > and recreate markup sounds more reasonable. You might save you lots > > of seeking time. > > > > But you always know: Only the code / application will tell you! > > > > > > Cheers, > > > > Martin (Kersten) > > > > -----Ursprüngliche Nachricht----- > > Von: Tobias Marx [mailto:[EMAIL PROTECTED] > > Gesendet: Dienstag, 18. März 2008 17:45 > > An: Tapestry users > > Betreff: @Cached and caching in general > > > > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
