Re: WO blocking/threading question
Re: WO blocking/threading question
- Subject: Re: WO blocking/threading question
- From: Hsu <email@hidden>
- Date: Sun, 15 Aug 2004 17:32:14 -0700
So if the RR loop is single threaded by default that means that if I
have 100 concurrent users all on 24600 bps modem connections that all
need to download a 50 k JPEG (i chose that number as it implies
roughly a 2 second download at 24.6kbps), that WebObjects will block
on each of those users while the output is being sent to the client or
just that the inital page generation is blocked.
So, you have several layers in a typical WO app.
Static resources are typically served by the WebServer (Apache, IIS,
etc). Requests for these are limited only by the webserver, not by
WebObjects. In the example above, if the JPG is a static image, WO
won't even be involved.
Dynamic resources (dynamic pages/images/files) are served by WebObjects
itself (through the webserver adaptor).
Starting with WO 5.0, the server-side adaptor is always multithreaded -
the actual request bytes are being transfered to WO, and the actual
response bytes are being returned to the client, are sent in parallel
(c.f. WOWorkerThreadCountMin and WOWorkerThreadCountMax).
Now, by default the RR loop is single threaded (though as David pointed
out, it can be made multithreaded with the
WOAllowsConcurrentRequestHandling flag). This means that while the
request is being processed, WO will block. This is basically page
generation. Note that in general, the single-threaded-ness only applies
to the provided request handlers (component, directaction and resource)
- any custom request handlers you write must opt-in to the scheme. This
also means that you can write special purpose handlers that run in
parallel to the rest of your app (I believe that Jon Rochkind wrote a
streaming file upload framework which does this), regardless of the
setting of WOAllowsConcurrentRequestHandling.
If you have a multi-threaded RR loop
(WOAllowsConcurrentRequestHandling==true), then requests may be
processed in parallel. Note that WO always serializes access to a
single session - in general, you cannot access a session from multiple
threads. Again, special purpose request handlers, WOLongResponsePage
(??) may be able to work around this issue. At this point, EOF locking
comes into play (if applicable, obviously).
EOF is basically threadsafe by being serialized; by default all EOF
operations go through a single database channel. As pointed out by
David, it is possible to create multiple database channels - I don't
about any consequences to having multiple channels (such as reconciling
data modifications across channels). It doesn't seem too difficult to
have a scheme where database channels are created on demand, but don't
quote me on that :)
And, of course, if your database only allows a single connection at a
time, all of the above is useless :)
Karl
--
Why is there a watermelon here?
Homepage:
http://homepage.mac.com/khsu/index.html
_______________________________________________
webobjects-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/webobjects-dev
Do not post admin requests to the list. They will be ignored.