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]
