On 12/17/06, Erik van Oosten <[EMAIL PROTECTED]> wrote:
Despite the trade off you depict very well, I can still the benefits of
this approach:
- no more session time outs,
That depends, then we also have to serialize the WebSession with every page.
The problem with that approach e is that you also rollback your websession
when using the back button....
So when you are now on page X and you go to Page Y and then Z by that you do
set something in the session
Then the user presses twice on the back button and you are back to page X
and you submit.
If then you also restore the session object you have lost the values what
you have done when you where in Y and Z
In our attempt to make it work see wicket 2.0 the
ClientPageSavingSessionStore class.
We only serialize the page itself. But not the session.
- infinite number of pages in pagemaps,
Thats already being solved by the SecondLevelCacheSessionStore
- and a bit more theoretic: smooth scalability. I say theoretic since it
is not likely you'll need this kind of scaling.
And that is just what igor was trying to explain. You will not get smooth
scalability
Because much more cpu power is needed and more importantly external
bandwidth.
johan
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
