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]
>
>

Reply via email to