Thanks for taking the time to put together a detailed reply. You've answered my question. Ray
-----Original Message----- From: Zvika Markfeld [mailto:[EMAIL PROTECTED]] Sent: Thursday, February 21, 2002 5:38 PM To: [EMAIL PROTECTED] Subject: Re: Single thread model in Tomcat 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 ___________________________________________________________________________ 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
