views:

102

answers:

5

Hi all,

Basically, how long is an instance of a servlet around for? I am kind of guessing it is session scope. However, I suppose it could have some sort of timeout or garbage collection to remove old instances.

Thanks, Grae

+4  A: 

A Servlet lives as long as the application does.

deamon
It can't be more than session scope. One user can't reference another user's servlet instance. Therefor, servlet instances are tied to session. Is that right? If they are tied to session, I would assume that go away after the session goes away.
Grae
No, Grae - users all use the same servlet instances.
vetler
Or am I wrong, maybe different users can share object variables in a HttpServlet.
Grae
Just to be clear, object level variables in a HttpServlet, shared between users?
Grae
There is only one instance of a particular servlet and all requests that map to that servlet, regardless of user, will go to that instance. Any variables in that instance will, of course, be there as well.
ColinD
A: 

A servlet is not bound to a session, it is a service object that is instantiated by the container when needed, and typically is kept alive for the full life of the webapp. It typically responds to requests from several clients (and sessions), even concurrent requests. That's precisely why your servlet code must be thread safe, and you never store in a servlet field some data associated to a request or a session.

leonbloy
A: 

when i remember correctly servlets live as Singletons in the Servlet Container (e.g. Tomcat). Im not sure if the first instantiation is lazy, meaning that the Servlet gets constructed only if needed, but im guessing one could check this in the corresponding Servlet Container's Classloader sources. The Servlet's lifecycle ends and it's destroy() method gets called when the Servlet Container is shut down. You can check this easily by setting up breakpoints or logging in the appropriate init() and destroy() methods and Constructor then just check when the code gets executed in your debugger/logfile.

hope that helped.

References: Tomcat's Classloader howto

smeg4brains
The first instance is usually lazy, you can control that in web.xml by setting `<load-on-startup>1</load-on-startup>`
nos
+7  A: 
  • a servlet is created when the application starts (it is deployed on the servlet container) or when it is first accessed (depending on the load-on-startup setting)
  • when the servlet is instantiated, the init() method of the servlet is called
  • then the servlet (its one and only instance) handles all requests (its service() method being called by multiple threads). That's why it is not advisable to have any synchronization in it, and you should avoid instance variables of the servlet
  • when the application is undeployed (the servlet container stops), the destroy() method is called.
Bozho
Why will synchronization mean anything up? I guess It might slow it down, but it doesn't seem like it would cause a dead lock.
Grae
it slows it down massively. This means each user will have to wait for another user to complete the request - unacceptable.
Bozho
+3  A: 

The lifecycle is well defined, and exposed through lifecycle methods exposed in init, service, and destroy methods of the Servlet.

And, despite what else is being said here, this is all you can count on from the specification. Basically, you get those three methods and a guarantee that Servlets are not thread safe. That a single servlet MAY be simultaneously accessed by one or more requests.

There is nothing in the specification that limits a servlet to one instance the container, if a container decides to, it can get a request, create a servlet, call it's init, then service, then destroy methods, and set it free for garbage collection.

Individual containers have potentially different implementations.

Most containers do create a single instance. But the specification does not guarantee that, so you shouldn't rely on it.

Also, consider something like Google App Engine. GAE is VERY aggressive is continually expiring and shutting down entire web apps that receive no traffic. If you have a lightly traveled site, you can very well expect the entire app to start up, init all of its services, init any load-on-startup servlets, execute the request, and then shut everything down. So, on GAE it's imperative that you have a very fast application startup in order to maintain any semblance of performance.

So, simply, what you can count on is what the specification says. Individual containers may offer different run time experiences.

Will Hartung