That's incredibly frustrating as there are very valid cases where you need to use the SingleThread model and still support more than 1 user. The SingleThreadModel is a necessary API - I don't think nothing horrible about it. As for thread safety, that's something programmers need to learn.
But anyway, thanks for the response. At least now I can stop wasting time looking through the documentation for the 50th time. I'll also look at the archives. Is there another free/cheap app server out there that supports SingleThreadModel with multiple servlet instances? -----Original Message----- From: craigmcc@localhost [mailto:craigmcc@localhost]On Behalf Of Craig R. McClanahan Sent: Friday, October 19, 2001 6:16 PM To: [EMAIL PROTECTED] Subject: Re: SingleThreadModel only giving 1 thread On Fri, 19 Oct 2001, Edward Ivanovic wrote: > Date: Fri, 19 Oct 2001 17:31:03 -0400 > From: Edward Ivanovic <[EMAIL PROTECTED]> > Reply-To: [EMAIL PROTECTED] > To: [EMAIL PROTECTED] > Subject: SingleThreadModel only giving 1 thread > > I'm using Tomcat 4.0 and have a servlet that implements SingleThreadModel. > In every other app server I've tried (WebSphere & WebLogic) multiple > instances of this servlet are created and handle concurrent requests. > > However, in Tomcat it only creates one instance of the servlet and other > users must wait to be processed. i.e. only 1 user at a time is served. > > I know that, strictly speaking, this does satisfy the Servlet spec, but I'm > suprised that Tomcat 4.0 would have chosen to handle SingleTheadModel in > this way - or is there a configuration option that I'm not setting > somewhere? > No, you are not missing anything. SingleThreadModel is a horrible API because it totally misleads people about thread safety. Therefore, I don't believe in encouraging people to use it by doing any more than the spec requires -- although anyone who wants to is welcome to submit a patch to Tomcat to make is support instance pooling for STM servlets. This has been discussed a few bazillion times before on this list, if you want to check the archives. Craig McClanahan
