Re: WebObjects scalability question - WOSession?
Re: WebObjects scalability question - WOSession?
- Subject: Re: WebObjects scalability question - WOSession?
- From: Ian Joyner <email@hidden>
- Date: Tue, 16 Nov 2010 15:22:15 +1100
On 16 Nov 2010, at 14:40, Chuck Hill wrote:
>
> On Nov 15, 2010, at 5:27 PM, Ian Joyner wrote:
>
>> On 16 Nov 2010, at 12:02, 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.
>>
>> Yes, it just illustrates the problem.
>>>
>>>> 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.
>>
>> Is that all client state or server (resource) state?
>
> It is things like:
> - which page uses which sandbox (EC)?
> - which objects have I moved into a sandbox?
> - what are the unsaved changes that I have made in a sandbox?
> - what is the state of a page as sent from the server?
>
> I'd consider that client state. Server state would be things like which snapshots are in the shared snapshot cache.
I think what Richardson and Ruby in RESTful Web Services would make of the sandbox would be to expose it as a resource. Now I'm not saying whether I agree or disagree with that. I'll have to give it some more thought. I certainly agree that sending a sandbox back and forth from client to server is very undesirable, if not insecure. Still the problem would be when to let a sandbox go because the user is just not going to get back to it. Perhaps even web services when you are talking to an automated client, not a slow user, the timeout could be very short, especially if you have control over the client and know how it behaves.
>
>
>
>> Long-lived transactions have always been a problem (from when I worked on Oracle SQL* and Transparent Gateway). I'm just trying to get my head around how restful WO could be or whether it falls into another class of applications. The book "RESTful Web Services" says that RPC services in contrast to resource-oriented services are for "the design of process-oriented, brokered distributed services". So is that what WO is best at?
>
> I don't know that there is a definitive answer to that. Certainly, I don't have it. With ERRest and planning, a WO app could be very RESTful. Some apps (at least IMO) are poorly suited for the REST model. The use of direct actions vs component actions would also seem to have an effect here. I look at REST as an architecture and WO as a set of tools. It can be used to build apps in the REST architecture and it can be used to build them in other architectures.
Well, I'm sure you'll agree REST is not even an architecture - it's an architectural style. The Web is an architecture based on the REST architectural style. A lot of it makes sense, but I'm still probing the limitations and trying to understand if REST covers 90%, what is the other 10% if any?
>
>
>> Sorry, I'm not trying to be difficult here, just be devil's advocate and pick your brains so I can better understand what are the best solutions for particular problems while avoiding the hype and flame wars. And WO is the best group around. I'm just applying what I teach our students (and yes they do know WO and EO now), not to get involved in hype or flame wars but to know enough to decide what is the best thing to use in any situation.
>
> It is an interesting topic.
>
>
> Chuck
>
>
>>>>>> How is this problem dealt with these days? WOnder?
>>>>>>
>>>>>> Thanks
>>>>>> Ian
>
> --
> Chuck Hill Senior Consultant / VP Development
>
> Practical WebObjects - for developers who want to increase their overall knowledge of WebObjects or who are trying to solve specific problems.
> http://www.global-village.net/products/practical_webobjects
>
>
>
>
>
>
>
_______________________________________________
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