I do have a ConnectionPool that is syncronized. I wonder if that is causing
the problem.
However, there is also some System.out.println(..) statements in the code for
debugging purposes. I took all of those statements out today and everything
was running quicker. Is the System.out.println(xx) statement syncronized?
I think there may be some problems with the Connection Pooling (we are using an
Oracle Database). I adapted the code from the book Core Servlets (didn't
change too much of the code, if any).
Lastly, we did change one of the tomcat options. Can't remember exactly what
the option was, but it was turned off by default (we've had other major
database problems at work and was pulled into that before I could dig back into
this too much).
Thank you for your response.
--Cam--
Quoting Kitching Simon <[EMAIL PROTECTED]>:
> Hi Cam,
>
> Servlets don't "have threads".
>
> Tomcat as a whole has a pool of threads for serving
> incoming requests (see the tag in
> $TOMCAT_HOME/conf/server.xml).
>
> Unless you do something unusual, tomcat creates
> *one* instance of your servlet, and only one.
>
> Any *tomcat* request-serving thread which happens to
> need to run your servlet as part of a request just goes
> ahead and calls the service method (doGet/doPost) on
> the single servlet instance. If some other thread is already
> inside the instance, then the normal synchronization
> mechanisms are applied - synchronized methods can
> have only one thread in them, but "normal" methods
> are just run by the multiple threads in parallel, etc.
>
> So, does your servlet declare some critical method
> to be "synchronized"? If so, this is the reason that
> multiple client requests can't be served in parallel. If
> not (and you haven't deliberately turned down the size
> of the tomcat thread pool to 1), then I cannot think of
> any other reason for the behaviour you are seeing.
>
> As far as I know, there is no standard method of
> telling any servlet-spec-compliant system to create
> a "pool" of servlet instances, and run different requests
> using different instances. There really isn't any point in
> such a mechanism, because if you've bothered to
> declare "synchronized" methods on the servlet, that
> implies that there is data which *needs* to be shared
> across threads - so a pool of objects would break any
> code that needs synchronized methods anyway. If
> you *do* have a major servlet method "synchronized",
> then you need to think about **why** you declared it
> like that, and if possible get rid of the declaration (maybe
> you can just synchronize a smaller block of code?)
>
> Cheers,
>
> Simon
>
> > -Original Message-
> > From: Algarve, Leila [SMTP:[EMAIL PROTECTED]]
> > Sent: Monday, January 08, 2001 12:08 PM
> > To: '[EMAIL PROTECTED]'
> > Subject:AW: Servlet and Multiple Instances
> >
> > Check if your servlet class implements SingleThreadModel, in this case
> one
> > instance of the servlet will be able to handle just one request.
> >
> > Leila
> >
> >
> > -Ursprüngliche Nachricht-
> > Von: Cam DeBuck [mailto:[EMAIL PROTECTED]]
> > Gesendet: Montag, 8. Januar 2001 07:12
> > An: [EMAIL PROTECTED]
> > Betreff: Servlet and Multiple Instances
> >
> >
> > I've written a servlet that is getting hit pretty hard. It works
> fine
> > when
> > just one user access hit. However, when they are multiple people
> hitting
> > the servlet, it seems like that it is only serving one person at a
> time.
> > Is
> > there some confirguration option that I am missing so that it can
> spawn
> > multiple threads. Any help would be appreciated. Thanks.
> > --Cam--
> >
> >
> -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, email: [EMAIL PROTECTED]
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
>
--Cam--
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
