tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ben Souther <>
Subject Re: Multiple requests sharing the same Servlet instance
Date Wed, 16 Jun 2004 14:36:05 GMT
>since the Servlets aren't true objects
A servlet is a true object. It gets instanciated by the container.

>since no local state is useful.
All the variables declared in your service methods (doPost, doGet)
are local to a particular request.

You also have access to application, session, and page scoped variables.

The servlet spec is a good read if you want to understand when and why 
an evironment will opt for multiple instances of a particular servlet.

SRV.2.2 Number of Instances The servlet declaration which is part of the 
deployment descriptor of theWeb application containing the servlet, as 
described in Chapter SRV.13,  Deployment Descriptor , controls how the 
servlet container provides instances of the servlet. For a servlet not hosted 
in a distributed environment (the default), the servlet container must use 
only one instance per servlet declaration. However, for a servlet 
implementing the SingleThreadModel interface, the servlet container may 
instantiate multiple instances to handle a heavy request load and serialize 
requests to a particular instance.

As a rule, I only use instance variables that are static and are initialized 
in the servlet's "init" method.

On Wednesday 16 June 2004 10:23 am, Keith Hankin wrote:
> Maybe I'm being dumb, but it seems to me that based upon what I'm hearing,
> there is no benefit of doing Servlet instance pooling since the Servlets
> aren't true objects; they are merely places to put code, since no local
> state is useful.
> ----- Original Message -----
> From: "Shapira, Yoav" <>
> To: "Tomcat Users List" <>
> Sent: Wednesday, June 16, 2004 7:06 PM
> Subject: RE: Multiple requests sharing the same Servlet instance
> > Hi,
> >
> > >But if a Servlet instance might be used by multiple threads at one
> >
> > time,
> >
> > >then what's the point of having Servlet object pooling at all? Why
> >
> > wouldn't
> >
> > It might and it might not.  My point was that the Servlet Spec leaves it
> > for the container implementation to decide, and so you should be
> > careful.
> >
> > >all requests just use one instance? I still don't see how I can have
> > >variables that are just for storing a single thread's working data. The
> >
> > You can do so easily inside any method, or in ThreadLocal variables, or
> > in request-scope attributes, or in other non-servlet object pools that
> > you write (or use a 3rd party pooling library).  The ways are plentiful
> > and except for the request attributes they're not specific to servlet
> > containers (nor is this issue in general specific to servlet
> > containers).
> >
> > >way I can do anything like this is to attach attributes to the request.
> >
> > But
> >
> > >this seems to be a kludge to me. I don't want to have to use Strings to
> >
> > get
> >
> > >to my data by way of a Map. I want regular Java local variables.
> >
> > Address your comments, suggestions, etc. to the Servlet Specification
> > JSR team (it's JSR154).  I'm just telling you what the spec guarantees
> > and what it doesn't ;)
> >
> > Yoav
> >
> >
> >
> >
> > This e-mail, including any attachments, is a confidential business
> communication, and may contain information that is confidential,
> proprietary and/or privileged.  This e-mail is intended only for the
> individual(s) to whom it is addressed, and may not be saved, copied,
> printed, disclosed or used by anyone else.  If you are not the(an) intended
> recipient, please immediately delete this e-mail from your computer system
> and notify the sender.  Thank you.
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> > For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

Ben Souther
F.W. Davison & Company, Inc.

This e-mail message, and any accompanying documents, is for the sole use of
the intended recipient(s) and may contain confidential and privileged
information.  Any unauthorized review, use, disclosure, distribution or
copying is prohibited.  If you are not the intended recipient, please
contact our office by email or by telephone at (508) 747-7261 and
immediately destroy all copies of the original message.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message