In what context are you refering to the back button here...Lets say we have two page instances of type "Page-A" through which we landed on "Page-B" which has a back button on it, now clicking the back butoon should load the "Page A" from the pageMap since its last accessed instance of Page-A...isnt it ? Why do you say that pressing the back button once will load the page from the disk...
Johan Compagner wrote: > > if you press the back button only once then the page needs to come from > disk. > > So if your users never use the back button then yes you only need to have > the last accessed page in the pagemap. > > johan > > On Nov 9, 2007 10:36 PM, mfs <[EMAIL PROTECTED]> wrote: > >> >> 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<http://nabble.com/> >> . >> >> >> --------------------------------------------------------------------- >> 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#a13677131 Sent from the Wicket - User mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
