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/archive%40mail-archive.com
This email sent to [email protected]
