You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by tsuresh <su...@hotmail.com> on 2007/09/23 10:01:44 UTC
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
Posted by Martijn Dashorst <ma...@gmail.com>.
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: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Session managment
Posted by Johan Compagner <jc...@gmail.com>.
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
Posted by Johan Compagner <jc...@gmail.com>.
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 <su...@gmail.com> 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 <su...@gmail.com> 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 <su...@hotmail.com> 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: users-unsubscribe@wicket.apache.org
> >>> For additional commands, e-mail: users-help@wicket.apache.org
> >>>
> >>>
> >>>
> >>>
> >> --
> >> 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: users-unsubscribe@wicket.apache.org
> >> For additional commands, e-mail: users-help@wicket.apache.org
> >>
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
> >
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Session managment
Posted by Suad AlShamsi <su...@gmail.com>.
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 <su...@gmail.com> 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 <su...@hotmail.com> 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: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>>
>>>
>> --
>> 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: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
>
Re: Session managment
Posted by Johan Compagner <jc...@gmail.com>.
nothing changed about that.
you still have to you detacheable models when using db data
On 10/20/07, alshamsi <su...@gmail.com> 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 <su...@hotmail.com> 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: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
> >
>
> --
> 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: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Session managment
Posted by alshamsi <su...@gmail.com>.
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 <su...@hotmail.com> 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: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
>
--
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: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Session managment
Posted by Eelco Hillenius <ee...@gmail.com>.
On 9/23/07, tsuresh <su...@hotmail.com> 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: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org