>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. =========================================================== Example: =========================================================== 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" <[EMAIL PROTECTED]> > To: "Tomcat Users List" <[EMAIL PROTECTED]> > 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: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
