myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Kienenberger <mkien...@gmail.com>
Subject Re: Super!
Date Thu, 20 Oct 2005 14:52:37 GMT
The way I did it under struts was to set a "creation date" mapping to
each page.    When pages were requested, before the page was looked
up, expiration dates were checked and expired pages were dumped.

My application was fairly low bandwidth, so I didn't spend much time
optimizing it, but I'd imagine you could record the "nearest creation
date" after each check, and then not do another full check until that
date was reached.    Then it's just one comparison per request until
another full check gets triggered, at which point you'd check
everything again and generate a new "nearest creation date".

I think I also checked the expiration dates on session expiration
events.  Not sure if that's necessary.

On 10/20/05, Mathias Brökelmann <mbroekelmann@googlemail.com> wrote:
> This sounds good to me. Any idea how we can implement it. The only
> solution I have is too have an additional thread running somewhere
> which checks for timeouts.
>
> 2005/10/20, Mike Kienenberger <mkienenb@gmail.com>:
> > I'd like to agree with Alexander on this one.   Sometimes, it's better
> > to be able to tell end users that their pages will expire after 5
> > minutes (or 5 hours) rather than saying they can only backtrack 15
> > views (most end-users have no idea what a "view" means).   Not all of
> > us need to tune our backtracking based solely on memory usage.
> >
> > -Mike
> >
> >
> > On 10/20/05, Mathias Brökelmann <mbroekelmann@googlemail.com> wrote:
> > > IMO having a max number of views stored in the session is quite
> > > adequate for this. If the user navigates to other pages the oldest
> > > view is dropped if the max number is reached. Correct me if I´m wrong
> > > but this is different to the RI. AFAIK RI stores the last n views
> > > based on a view. So you can end up with:
> > >
> > > number of pages (view) * max number of saved views = max number of
> > > saved views in session
> > >
> > > I don´t like this solution since it produces unpredictable results in
> > > memory consumption. myfaces solution now stores only the last n number
> > > of rendered views in the session.
> > >
> > > If there is a memory problem the user might choose to use client side
> > > state instead or reduce the number of views in the session.
> > >
> > > 2005/10/20, Jesse Alexander (KBSA 21) <alexander.jesse@credit-suisse.com>:
> > > > -----Original Message-----
> > > > org.apache.myfaces.NUMBER_OF_VIEWS_IN_SESSION
> > > > defines the number of the latest views stored in the session with a
> > > > default of 20 (like RI)
> > > > -----/Original Message-----
> > > > Great... one less test/investigation I have to do before being able to
> > > > request that JSF gets mandatory for our company's webapps ;-)
> > > >
> > > > I am just now wondering whether a timeout value for such session-view
> > > > objects might make sense as a further tuning mechanism.
> > > > The idea is to sort of clean the session from view that are called only
> > > > once (eg. login-usecase) or very seldom...
> > > >
> > > > especially for big apps with lots of users this could be crucial.
> > > >
> > > > Or should we device something that would allow this mechanism to be
> > > > configured
> > > > per page. EG. the login pages do not need to remain in the session...
> > > >
> > > >
> > > > regards
> > > > Alexander
> > > >
> > >
> > >
> > > --
> > > Mathias
> > >
> >
>
>
> --
> Mathias
>

Mime
View raw message