I think it's also very much worth pointing out that client-side state has huge implications for security; as developers we basically should not trust anything that is supplied to us by the client. For any non-trivial app that actually requires session state be stored, the chances are high that you don't want malicious users to be able to mess with the internals of their session.
--
Simon J. Oliver CISSP-ISSAP, ISSMP, GWAPT
Applied Information Technology Center/SBBER University of Memphis, TN
On Nov 15, 2010, at 7:02 PM, Chuck Hill wrote: On Nov 15, 2010, at 4:53 PM, Ian Joyner wrote: On 16 Nov 2010, at 11:35, David LeBer wrote:
On 2010-11-15, at 7:09 PM, Ian Joyner wrote:
(Not that I'm doing any WO these days, but I still like to follow.)
One thing that has always worried me about scalability is keeping the per user "application state" on the server in WOSession. Knowing more about REST now, this is very unrestful and not stateless, which means will not scale.
I don't see why something being unrestful and not stateless automatically equates to not being able to scale. Perhaps you could explain.
The problem is that once you get 1000s and millions of users you have the problem of memory size storing all that session information in memory on the server.
As with any system, the number of concurrent users that can be handled on a given server depends on both the application and the technology that it is built on. I will grant you that WO probably uses more memory per user than many technologies. But memory usage is only one part of the equation. Server must also manage all these sessions - clean them out every so often. And (in middleware systems I worked on in the 80s) keep track of state transitions with FSMs, etc.
Yes you need session state, ie context, but it should be kept on the client, which sends it along with each request. Thus user state is kept only on the client which makes recoverability easier too, because if the server is rebooted, client can continue oblivious to any problem.
Yes, recoverability is a nice to have feature, but really how often is it actually needed? Restarts should be planned with the instances being set to Refuse New Sessions so that there are no active sessions on a machine when it is rebooted. So recoverability is only strictly needed for accidental restarts, kernel panics and such. The problem with keeping the WO state on the client is that WO keeps a LOT of state (EO, changed attributes, page cache, etc). You would need to have a finely tuned way of getting that back and forth from the client, otherwise performance would suffer mightily. Chuck
|