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 (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
