Session managment
Hello, can someone please explain me how Session handling works in wicket 1.3. It would be better if you explain with an example. -- View this message in context: http://www.nabble.com/Session-managment-tf4503470.html#a12843600 Sent from the Wicket - User mailing list archive at Nabble.com.
Re: Session managment
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]
Re: Session managment
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]
Re: Session managment
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]
Re: Session managment
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]
Re: Session managment
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]
Re: Session managment
First of all don't worry that much about the session usage, in 1.3 we only store 1 page per pagemap in the session, the rest is stored to disk > 1. So, Can I manually interval the session and remove the objects stored > in the session? > What kind of objects? If you store the object in the Wicket session object, then they are in the session And what is that interval? A scheduler? You shouldn't touch sessions when the request isn't happening. 2. Can I manually view all the objects stored in a session? > We have some debug tools like page inspector, See examples for that. 3. If the size of the page map is set to 5 for example does that mean that > these 5 pages and associated components, models will be stored in the > session and other will be removed from the session? > In wicket 1.2 yes. in wicket 1.3 that size isn't being used anymore. Only the active page is there. 4. The default first cache level is the file system. So what will have if I > sit a limit of the file system size? Will it override it? Will the lost > components be created again instead of being retrieved from the cache? > Currently you can control what the window is that a session gets. i think by default it is 10MB or something like that. So 1 session will not grow out of control. If of course you have a full disk then sessions can't be saved and those are lost. But do remember that those pages on disk are pretty much only there for the back button' If the users don't use the backbutton then the disk is not used for reading the pages back in. 5. What are the best practices of handling a session? > Just let wicket handle it. Don't store objects directly in the http session your self (use the wicket session object for that) Also use detachable models for you data. Don't keep the whole database in memory between request. That will greatly explode your pages. johan >
Re: Session managment
What heavy session drawback are you talking about? Martijn -- Buy Wicket in Action: http://manning.com/dashorst Apache Wicket 1.3.0-beta4 is released Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0-beta4/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]