Craig R. McClanahan wrote:
>
>>This is true in a very particular situation. Basically, a servlet
>>container will instantiate ONE servlet class into an object. Each
>>request is handled via it's own separate thread. Unless Servlet
>>implements SingleThreadModel, all threads that are directed to that
>>particular servlet will activate it's "service()" method and run in
>>paralel.
>
> This is actually the *normal* case -- not any kind of exception.
Yup.
>>In the oposite case, threads will synchronize on that Servlet.
>>If I understand things correctly, it is not the servlet that creates
>>threads for each request - it is the particular Connector, which than
>>forms the request and forwards it to the appropriate handler, filter or
>>a servlet.
>
> You are correct in one respect; the servlet creates the necessary threads.
> However, you are (potentially) incorrect in another respect -- the
> container will ***never*** synchronize on servlet instance whose class
> does not implement SingleThreadModel -- the typical pattern is that a
> single (nont-STM) servlet instance is processing multiple requests at the
> same time.
Well, that is what I said ("In the opposite case..."), but thanks for making it
clear.
> If you are using SingleThreadModel (STM) servlets instead, the container
> guarantees that no more than one request at a time is active in any given
> instance -- it ***may*** use synchronization on servlet intsances to
> enforce this, but that is an implementation detail and is not guaranteed.
I mentioned that as a reasonable and vague option. I don't know what exactly
does Tomcat synchronize on, but the idea is that a Servlet Container must
synchronize on something in case of STM servlet.
> There is no such thing as a SingleThreadModel filter -- filters must
> ***always*** be programmed to be thread safe.
I never meant to imply that there was, but again, thanks for being specific.
>>So, the only occasion when the same thread would handle TWO requests,
>>regardles of who's the originating client, would be when there is a
>>thread-pool and first request finishes and the available thread for the
>>other request is the one that handled the first one. This is a game of
>>chance. Again, I haven't looked into Tomcat internals, but this is how I
>>picture any servlet container would work.
>>
>>
>
> It appeares you also haven't looked at the servlet spec :-).
Being the only volounteer at my site to build/test/deploy Sendmail, Cyrus,
Apache, PostgreSQL and Tomcat on Tru64 UNIX, I'm lucky to be breathing. :-)
> It is not legal (or even technically possible) for a single thread to
> process more than one request at the same time. Threads are allocated to
> a particular request for the lifetime of that request, and then reused.
Is there some kind of "retirement" of threads? You know, to prevent memory
leaks, so that each thread has a maximum number of times it can be reused.
Nix.
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
