You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by du...@bankone.com on 2003/09/29 23:21:18 UTC
Tomcat Request Handling Question
Hello,
Re: Tomcat Request Handling Question
Posted by Bill Barker <wb...@wilshire.com>.
The Servlet spec (2.2-2.4) requires that each Request is handled by a single
Thread. Especially with the Jk2-Coyote connector (that links Tomcat to
Apache/IIS/SunOne), the thread may be re-used for requests from different
clients. However, it will always serve one Request from start-to-finish
before starting another one. At a guess (since I obviously can't see it :),
I'd guess that your implementation is sub-optimal, but will work.
<du...@bankone.com> wrote in message
news:OF4BF3386C.EC4E3003-ON85256DB0.0074CFFA@bankone.com...
>
> Hello,
> From not having too much experience programming threads I have run into a
> design snag that I need some help with. Long story short, I need to be
> absolutely sure that the tomcat servlet container handles each request in
a
> unique thread. So (for example) if there are 300 simultaneous connections
> they are processed in 300 unique threads.
>
> The reason behind this desperation is because I have created a framework
> that uses the threadlocal class to create a singleton like class for each
> request that stores references to the request and response objects so all
> classes during the request can access these objects without having to pass
> parameters around from class to class. If for some reason 2 different
> requests were handled in the same thread that could be a huge flaw in my
> design. Thanks!
>
>
> Duncan Krebs
> Bank One
>
>
>
>
>
>
> This transmission may contain information that is privileged, confidential
and/or exempt from disclosure under applicable law. If you are not the
intended recipient, you are hereby notified that any disclosure, copying,
distribution, or use of the information contained herein (including any
reliance thereon) is STRICTLY PROHIBITED. If you received this transmission
in error, please immediately contact the sender and destroy the material in
its entirety, whether in electronic or hard copy format. Thank you.
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: Tomcat Request Handling Question
Posted by Bill Barker <wb...@wilshire.com>.
The Servlet spec (2.2-2.4) requires that each Request is handled by a single
Thread. Especially with the Jk2-Coyote connector (that links Tomcat to
Apache/IIS/SunOne), the thread may be re-used for requests from different
clients. However, it will always serve one Request from start-to-finish
before starting another one. At a guess (since I obviously can't see it :),
I'd guess that your implementation is sub-optimal, but will work.
<du...@bankone.com> wrote in message
news:OF4BF3386C.EC4E3003-ON85256DB0.0074CFFA@bankone.com...
>
> Hello,
> From not having too much experience programming threads I have run into a
> design snag that I need some help with. Long story short, I need to be
> absolutely sure that the tomcat servlet container handles each request in
a
> unique thread. So (for example) if there are 300 simultaneous connections
> they are processed in 300 unique threads.
>
> The reason behind this desperation is because I have created a framework
> that uses the threadlocal class to create a singleton like class for each
> request that stores references to the request and response objects so all
> classes during the request can access these objects without having to pass
> parameters around from class to class. If for some reason 2 different
> requests were handled in the same thread that could be a huge flaw in my
> design. Thanks!
>
>
> Duncan Krebs
> Bank One
>
>
>
>
>
>
> This transmission may contain information that is privileged, confidential
and/or exempt from disclosure under applicable law. If you are not the
intended recipient, you are hereby notified that any disclosure, copying,
distribution, or use of the information contained herein (including any
reliance thereon) is STRICTLY PROHIBITED. If you received this transmission
in error, please immediately contact the sender and destroy the material in
its entirety, whether in electronic or hard copy format. Thank you.