any variable declared inside your service(request,response) method (actually any method) are thread specific, since they are added to a separate thread stack. hence you can have 20 threads executing the same servlet, and your method variables will never be shared.
Filip ----- Original Message ----- From: "Keith Hankin" <[EMAIL PROTECTED]> To: "Tomcat Users List" <[EMAIL PROTECTED]> Sent: Wednesday, June 16, 2004 8:33 AM Subject: Re: Multiple requests sharing the same Servlet instance > 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 > 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 only > 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. > > Why not just > ----- Original Message ----- > From: "Shapira, Yoav" <[EMAIL PROTECTED]> > To: "Tomcat Users List" <[EMAIL PROTECTED]> > Sent: Wednesday, June 16, 2004 6:47 PM > Subject: RE: Multiple requests sharing the same Servlet instance > > > > > > Hi, > > No, it doesn't mean one instance of a servlet class is created. It > > means the container is free to pool the instances any which way it > > likes, optionally adjusting for load, destroying unused servlets to save > > resources, etc. The lifecycle of a servlet is not necessarily related > > to its pooling, they address separate concerns. > > > > You have a whole host of options for where to put temporary data used by > > a servlet, as you do in general for java classes. The design > > considerations for synchronization are the same as whenever you design > > an object that can be used by multiple threads concurrently. > > > > Yoav Shapira > > Millennium Research Informatics > > > > > > >-----Original Message----- > > >From: Keith Hankin [mailto:[EMAIL PROTECTED] > > >Sent: Wednesday, June 16, 2004 9:14 AM > > >To: Tomcat Users List > > >Subject: Re: Multiple requests sharing the same Servlet instance > > > > > >So this means that only one instance of a given Servlet class is every > > >created? How does one do any real work with this? Where do I put my > > >temporary data if not in attributes of the Servlet instance? And what > > is > > >the > > >reason for having a life cycle of Servlets, with init/destroy methods? > > I > > >thought it would use Servlet instance pooling. > > > > > >----- Original Message ----- > > >From: "Shapira, Yoav" <[EMAIL PROTECTED]> > > >To: "Tomcat Users List" <[EMAIL PROTECTED]> > > >Sent: Monday, June 14, 2004 8:22 PM > > >Subject: RE: Multiple requests sharing the same Servlet instance > > > > > > > > >> > > >> Hi, > > >> I don't think your understanding is correct: the container may allow > > >> multiple threads to use the same servlet instance concurrently. If > > you > > >> need synchronization around or within that method, or around some > > fields > > >> in your servlet class, you are responsible for it. > > >> > > >> The container does guarantee that only one thread will process a > > request > > >> from start to finish, i.e. the same thread will invoke any filters, > > >> servlets, etc. for the same request. > > >> > > >> Yoav Shapira > > >> Millennium Research Informatics > > >> > > >> > > >> >-----Original Message----- > > >> >From: Keith Hankin [mailto:[EMAIL PROTECTED] > > >> >Sent: Monday, June 14, 2004 10:53 AM > > >> >To: Tomcat Users List > > >> >Subject: Multiple requests sharing the same Servlet instance > > >> > > > >> >I am having a problem where one Servlet instance seems to being used > > by > > >> two > > >> >different threads at the same time. It is my understanding that > > Servlet > > >> >instances will not be used by two threads at the same time, so that > > the > > >> >service() method would thus only be called by one thread, then it > > can > > >> be > > >> >called again if the Servlet instance is reused by way of pooling. > > >> > > >> > > >> > > >> > > >> 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] > > > > > > > > > > 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
