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]
