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 <[EMAIL PROTECTED]>: > 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 <[EMAIL PROTECTED]> 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) <[EMAIL PROTECTED]>: > > > -----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
