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 >
_______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
