Hi, It's not hard to do it with Wicket, but I'm fairly sure that for the typical web-app, the metrics showed that the a re-request to database wasn't a big issue, whereas the gain in terms of reducing the session size was, especially where it needs replicating.
As such, the recommendation is as it is, but it's not one-size-fits-all, and if you have a large enough percentage of non-DB-cachable operations in the DB-layer, you can store the results in the session, etc, without much of a problem. It's not going to be so built-in as to be trivial, though, as we want to make it clear that anyone doing that is going against the flow. On 09 November 2007, 9:03:31 AM, serban.balamaci wrote: sb> Most database expensive operations come from the result of stored sb> procedures(my current experience at least). A cache solution can be sb> implemented by caching the method results with spring(in case of using sb> spring) but is a heavy(difficult) thing to maintain that "cache" per user - sb> http session is a nice and easy storage for that-. sb> Eelco Hillenius wrote: >> >>> You should use a second level cache to cache objects and queries from >>> your database; and that's not Wicket's job, Wicket is a Web framework. >>> >>> For example, use Hibernate + ehcache. >> >> Yep. That way you'll avoid redundancy in caching, and have caching >> regardless of whatever UI framework you're using. and using e.g. >> ehcache can do things for you like limit the RAM cache and overflow to >> disk. Etc. >> >> Eelco -- /Gwyn --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
