+1 S. Tunji Turner sightuary / firstsightmedia
On Nov 19, 2010, at 10:16 AM, André Mitra <[email protected]> wrote: > wirehose beckons, but where is gary... > > On 2010-11-19, at 9:17 AM, Jean-Francois Veillette wrote: > >>>>> 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. 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. >>>> >>>>> How is this problem dealt with these days? WOnder? >> >> >> I have seen this problem solved as a WO solution. >> It was summer 2000 (yes, 10 year ago), and I was in a meeting of software >> engineer where people showed what they did and how they did it [1]. >> The engineer had to solve the problem of application's instance needing to >> restart while keeping 100% uptime for users ... the client was the us navy >> (or was it us postal?). >> What he did was to encrypt and push enough information on the page so that >> on the next submit, the application can find who you are, what are the eos, >> which action you want to execute and be able to resume from a server crash >> or app restart. >> >> This is how I remember it ... >> - eavy use of DirectAction (/wa/) while maintaining the component action >> (/wo/) feel, >> - wo form elements where all subclassed and needed different binding to get >> the eo separately from the keypath. >> For example a wotextfield binding would look like: >> UserName_TextField: WOXXTextField { eo = aUser; keypath = name; } >> and when the textfield generated html, the globalid for 'aUser' was somehow >> pushed in the form along with the 'keypath' (obviously encrypted). >> On form submit, even if the session no longer exist, the textfield was able >> to get back to your 'aUser' EO and able to push the new 'name' value on it. >> In the end, all in all, you got your context back and was able to execute >> your (direct)action. >> I do not remember enough details, but from what I remember that was the idea. >> >> So to answer your question ... >> No, plain WebObject still doesn't deal with this problem ... but I hope you >> got enough idea here to start a new implementation. >> Yes, Apple internaly have code that can deal with it [2]. >> >> PS: Mike (or any one inside Apple who read this message), it would be nice >> if such code could be seen from the outside of Apple >> >> [1] iService's meeting in Washington area (?Reston?) >> [2] It went in the « ObjectWare » library (? I hope that was the name ?), an >> internal equivalent of « sourceforge » inside Apple. >> >> jfv >> >> >> >> _______________________________________________ >> Do not post admin requests to the list. They will be ignored. >> Webobjects-dev mailing list ([email protected]) >> Help/Unsubscribe/Update your Subscription: >> http://lists.apple.com/mailman/options/webobjects-dev/andre%40geometria.net >> >> This email sent to [email protected] > > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Webobjects-dev mailing list ([email protected]) > Help/Unsubscribe/Update your Subscription: > http://lists.apple.com/mailman/options/webobjects-dev/vision%40firstsightmedia.com > > This email sent to [email protected] _______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [email protected]
