to be clear - in the above post, we keep no "state" in the server other than the info associated with the session ID, and that info is NOT stored in the Session Context. As many have found in the past, storing session state leads to performance issues in session serialization and server sync cross-talk in J2EE clusters. Even tho the data kept is like 128 bytes ( which would seem harmless ), it still leads to significant I/O for a LARGE number of users. Terracotta could be used to bypass this and store alot of data in the session, but architecturally, we just don't do it as a rule.
We do cache certain expensive queries, some associated with user ID's, but they are expired after a timeout or FSM root change. ( this is used in the case of say... showing a table of hundreds/thousands of instruments in a portfolio, but the table has paging and sorting ) --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~----------~----~----~----~------~----~------~--~---
