there are loads of imovements. like better stateless support , better delayed session support and the last few days improvements in what the basic component cost in mem. But things you do with that is up to you , if you just drop a large list in a basic model then wicket doesnt know that.
On 10/20/07, Suad AlShamsi <[EMAIL PROTECTED]> wrote: > So there is no improvement on the heavy session drawback?! > > Johan Compagner wrote: > > nothing changed about that. > > you still have to you detacheable models when using db data > > > > > > On 10/20/07, alshamsi <[EMAIL PROTECTED]> wrote: > > > >> Hi, > >> How does wicket 1.3 handle sessions differently than wicket 1.2? > >> Assume that I am using wicket 1.3 and I need to reteive too many records > >> from the database, will these records be stored in the user session? Will > >> wicket handle that or do I need to use the detach model? > >> > >> Regards, > >> AlShamsi > >> > >> > >> Eelco Hillenius wrote: > >> > >>> On 9/23/07, tsuresh <[EMAIL PROTECTED]> wrote: > >>> > >>>> Hello, can someone please explain me how Session handling works in > wicket > >>>> > >>> Wicket has it's own abstraction of user sessions: > >>> org.apache.wicket.Session, though you'll typically use a derivative > >>> like WebSession. *Typically* - depending on the session store > >>> (ISessionStore) you use, Wicket sessions are linked to the Servlet > >>> API's HttpSessions. If they are, Wicket sessions are stored in > >>> HttpSessions if the HttpSessions exist yet, or they are temporary > >>> (just for the current request) otherwise. > >>> > >>> Wicket provides it's own abstraction to give you more flexibility > >>> independent of the servlet container you use in where sessions are > >>> stored, and it also tries to encourage you to code session variables > >>> in a strongly typed fashion. > >>> > >>> Pages are stored in page maps. You can compare page maps with browser > >>> windows. Page maps are created by session stores, but they can > >>> implement persistency of pages independently. > >>> > >>> The default session store implementation for Wicket 1.3, > >>> SecondLevelCacheSessionStore (extends HttpSessionStore), stores Wicket > >>> session objects in the HttpSession, but pages in cache. First level of > >>> cache is simply RAM and is used for the current page (since there is a > >>> big chance it will be hit in the next request), second level cache is > >>> implemented through an implementation of IPageStore, which by default > >>> serializes pages to a temp file per session. Pages are typically only > >>> read from second level cache when the user pushes the back button. > >>> > >>> > >>>> 1.3. It would be better if you explain with an example. > >>>> > >>> If you really want to understand it, pick up wicket-examples and place > >>> some break points here and there to see what happens. > >>> > >>> Eelco > >>> > >>> --------------------------------------------------------------------- > >>> To unsubscribe, e-mail: [EMAIL PROTECTED] > >>> For additional commands, e-mail: [EMAIL PROTECTED] > >>> > >>> > >>> > >>> > >> -- > >> View this message in context: > >> http://www.nabble.com/Session-managment-tf4503470.html#a13309608 > >> Sent from the Wicket - User mailing list archive at Nabble.com. > >> > >> > >> --------------------------------------------------------------------- > >> 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]
