I'm interested in Dean's comments on performance impact of session data which seems counter intuitive to me (not that I doubt you at all Dean, just want to understand!)
1/ The session is going to be stored anyway right. That's part of the contract with the client. I don't know what this equates to in terms of bytes but I guess it's not less than a 100. 2/ ytrewqsm's original problem would be solved by storing one single long in the session: the user ID. The session is 'secure enough' for many applications (banking, etc., excepted). Each service request made by the client in the context of that session can be authenticated 3/ We can't, and don't need to avoid being platform specific - we are talking GAE not WebSphere, WebLogic, JBoss, ... My guess is that the session will be stored somewhere in BigTable and will be scalable. 4/ For all other state needs - throw them at the client. There's a bunch of memory and CPU power out there that's free for the application - use it but keep an eye on client performance The alternative has a large impact on the design of the client raising the entry barrier significantly and I don't think that's in line with GAE's endgame. > 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 --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~----------~----~----~----~------~----~------~--~---
