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
