Well, i believe if someone is aware of these issues, there's nothing wrong with using this solution - I've had some cases where data access is fast but data processing (in order to present) was quite complex, so this really helped.
For reference, another not-yet-mentioned problem of this kind of cache is the jsessionid parameter that may be cached in url (though we / many people completely remove them nowadays) On Wed, Mar 19, 2008 at 1:55 AM, Howard Lewis Ship <[EMAIL PROTECTED]> wrote: > I'm generally against these approached. > > Cache the data, make it fast to access. > > Let Tapestry do a full render every time. > > You'll end up with confusing, unforseen consequences. > > Rendering is increasingly a complex dance between components. That's > the power and the penalty of Tapestry. Components inside that cached > zone are not just rendering a character stream, they are generating > JavaScript, assigning unique ids (via PageRenderSupport) interacting > with an enclosing Form components, and doing other user-specific > things. > > I would always look elsewhere first for places that need optimization, > and I'd start with database access and queries. > > > > On Tue, Mar 18, 2008 at 11:22 AM, 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] > > > > > > > > > -- > Howard M. Lewis Ship > > Creator Apache Tapestry and Apache HiveMind > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Andreas Andreou - [EMAIL PROTECTED] - http://blog.andyhot.gr Tapestry / Tacos developer Open Source / JEE Consulting --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
