Re: WebObjects scalability question - WOSession?
Re: WebObjects scalability question - WOSession?
- Subject: Re: WebObjects scalability question - WOSession?
- From: Tunji <email@hidden>
- Date: Fri, 19 Nov 2010 10:32:50 -0500
+1
S. Tunji Turner
sightuary / firstsightmedia
On Nov 19, 2010, at 10:16 AM, André Mitra <email@hidden> 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@hidden)
>> Help/Unsubscribe/Update your Subscription:
>>
>> This email sent to email@hidden
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Webobjects-dev mailing list (email@hidden)
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden