Hibernate makes it easy to do some really interesting things without a great deal of thought.
Any time you start working with large data sets you have to think carefully about what Hibernate is doing on your behalf - like the inner loop example. For some reporting tasks, you might want to use Hibernate to generate a recordset from raw SQL. For other cases, changing a fetch strategy from LAZY to EAGER will address the performance issues. A substitute for your existing caching, depending on memory requirements, might be to implement a results-cache as a service within your Tapestry app. Mimic what is done currently, but perhaps schedule refreshes with Quartz and keep it within the same app. Jonathan > -----Original Message----- > From: Tobias Marx [mailto:[EMAIL PROTECTED] > Sent: Tuesday, March 18, 2008 1:35 PM > To: Tapestry users > Subject: AW: @Cached and caching in general > > I had the idea while looking at this benchmark here: > > http://www.dmst.aueb.gr/dds/pubs/conf/2002-SANE- > DynCont/html/throughput.gif > > I am currently trying out Resin as it allows to use PHP and Servlets at > the same time - so you can mix old PHP code with Tapestry on a single > webserver and replace parts of the web application with PHP or Tapestry > depending on whats faster in a certain situation. > > A typical example I have problems with in Tapestry/Hibernate is the > following: > > - a table that displays an object > - buttons or additional components on the table cells that depend on other > objects > > In this case you have several database queries....one for the outer loop > and one for the inner loops. > > In theory you could define a virtual new object in Hibernate that does > some joins or unions that will result in just one query in the outer > loop...and then it works quite fast. > > I like Hibernate as long as you can use your objects directly...but using > Hibernate for joins and unions is not much fun.... > > So such a table would benefit a lot if is was cached...even if the > individual queries would be cached you still had to do all the loops and > parsing of the templates. > > > -------- Original-Nachricht -------- > > Datum: Tue, 18 Mar 2008 18:22:01 +0100 > > Von: "Martin Kersten" <[EMAIL PROTECTED]> > > An: "Tapestry users" <users@tapestry.apache.org> > > Betreff: AW: @Cached and caching in general > > > You might want to know what tapestry does with your templates. > > Tapestry reads your template and parses it - only once it changes! > > So generating two pages (even with different content) just results > > in using a parsed, preprocessed in memory representation of your > > template. So tapestry strictly avoids disk-access and parsing > > in production (when processing all templates on startup is > > enabled). > > > > So there is no need for the older cache it hack. As I mentioned > > it is easy to play with your own cache implementation. But be > > carefull about the components you place inside your cache. You > > know context and event handling. But for displaying 'cached' content > > it might be an option. > > > > If you go ahead and try it you may post your benchmarks. I don't > > know who has stretched it before but I guess caching is always a > > hot topic so if you can provide new insides your are welcome. > > > > > > Cheers, > > > > Martin (Kersten) > > > > > > > > -----Ursprüngliche Nachricht----- > > Von: Tobias Marx [mailto:[EMAIL PROTECTED] > > Gesendet: Dienstag, 18. März 2008 18:15 > > An: Tapestry users > > Betreff: AW: @Cached and caching in general > > > > > The problem is context I guess. Usally your component depends on lots > > > of stuff. Parameters, URL, Services, Page-state, component state, > > > HTTP-Parameters and so on. > > > > Yes...but it must be possible somehow as some PHP template engines also > do > > it. Isn't there already some mechanism in the internals of Tapestry that > > keeps track of that even now? > > > > --------------------------------------------------------------------- > > 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]
