Hi Ray,
By default every request triggers a thread invocation on the same servlet
instance. Unless your "other" object (the one that is instantiated and used
by the servlet) is a class or instance member, you need not worry about
Servlet pooling etc.: The local variables of your service() method are
duplicated per thread.

Now let's examine the other case, where the "other" instance is, indeed,
common to all requests and therefore needs to be synchronized. In this
scenario, implementing the SingleThreadModel might mean that, as other
members as yourself have pointed out, all calls to service are synchronized
and you are potentially creating a hysterical bottleneck. Even if Tomcat
manages a servlet pool for that purpose, you are loosing portability here
since other servlet engines might not. Betterstill, if your "other" object
is an expensive one (weight a lot, opens sockets/connections/threads etc.)
you are facing a potential performance problem since you generally have no
control over the pool size. Either way you're shagged. This is why the
SingleThreadModel is not highly recommended for general usage.

What can you do, than?
1. Create the object locally inside service() method
2. Manage you own pool of objects from servlet code.
3. If writing JSPs, you may consider using a caching mechanism such as the
one that OpenSymphony or iPlanet taglibs offer. This would mean that the
heavy processing would be carried out only once every predefined interval.
This would also obviously mean that clients will usually get a 'stale'
version of your content, if you can afford it.
4. If using servlets, you can create your own caching mechanism.

hope that helps,
zm.

-----Original Message-----
From: A mailing list for discussion about Sun Microsystem's Java Servlet API
Technology. [mailto:[EMAIL PROTECTED]]On Behalf Of Bivens,
Raymond E.
Sent: Thursday, February 21, 2002 8:34 PM
To: [EMAIL PROTECTED]
Subject: Re: Single thread model in Tomcat


Maybe I should re-phrase my question to be more specific...

If we have an instance of our servlet instantiate another class (to do
testing-related stuff) that's not registered by Tomcat, do we have to worry
about threading issues among these other classes?

In other words, servlet X instantiates class Y that's not registered with
the servlet container. If multiple Xs instantiate multiple Ys, is there a
chance that the class-level (instance) variables in Y1 and Y2 can get
corrupted by each other's data?

As I understand it, this could potentially happen when dealing with
servlets, but what about classes instantiated by a servlet but not
registered with the servlet container?

Thanks.
___________________________________
Ray Bivens



-----Original Message-----
From: Christopher K. St. John [mailto:[EMAIL PROTECTED]]
Sent: Thursday, February 21, 2002 11:23 AM
To: [EMAIL PROTECTED]
Subject: Re: Single thread model in Tomcat


"Bivens, Raymond E." wrote:
>
> Since the tests can be quite lengthy anyway, my logic is
> to use a single threaded model
>


 I'm not following your logic. How does the fact that the
tests are lengthy imply you have to use SingleThreadModel?


--
Christopher St. John [EMAIL PROTECTED]
DistribuTopia http://www.distributopia.com

___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".

Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html

___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".

Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html

___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".

Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html

Reply via email to