I agree..and i would say its mostly the nature of the applications which would help determining whether storing the data in the wicket session would be a good idea or not...
Further i believe that 99% of the times one just comes to the need of accessing the last page-instances (lets say through back button link or otherwise doing a refresh if on the same page)...i still couldnt think of scenarios where the older page-instances (which are being serialized) would come to help...If someone could discuss/point some of those sceanrio/use-cases..that would be helpful..and would be able to better justify the wicket's default behavior of serializing. Thanks and Regards, Farhan. Gwyn wrote: > > 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] > > > -- View this message in context: http://www.nabble.com/Disabling-serialization-storage-of-pages-in-session--tf4768006.html#a13675586 Sent from the Wicket - User mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
