jump to navigation

Servlet Lifecycle August 23, 2005

Posted by Coolguy in Servlets/Jsp.


  • Servlet starts life when container finds the servlet class file.
  • This happens when container starts up.
  • Finding the class is the first step
  • Loading the class is second step
  • Loading happens on container startup or on first client use.
  • Web container instantiates the servlet and the default constructor of the servlet runs. Constructor makes only a object not servlet.
  • Container then initializes the servlet by calling init() on servlet.
  • The init() method is called only once in servlet’s lifecycle.
  • This happens only once after the servlet instance is created but before the servlet can service any requests.
  • init() method gives servlet access to ServletConfig and ServletContext objects
  • Initialization of servlet(getting db connections etc) can be done here.
  • Container calls service() to handle client requests.
  • Each request runs in a separate thread. There is only one instance of any servlet class
  • Service calls doGet() or doPost()
  • Container ends the servlet by calling destroy()
  • Container runs multiple threads to process multiple requests to a single servlet.
  • Its one thread per request. Not one per client.


  • A servlet is managed through a well defined life cycle that defines how it is loaded and instantiated, is initialized, handles requests from clients, and is taken out of service.
  • This life cycle is expressed in the API by the init, service, and destroy methods of the javax.servlet.Servlet interface that all servlets must implement directly or indirectly through the GenericServlet or HttpServlet abstract classes.
  • The servlet container is responsible for loading and instantiating servlets. The loading and instantiation can occur when the container is started, or delayed until the container determines the servlet is needed to service a request.
  • When the servlet engine is started, needed servlet classes must be located by the servlet container. The servlet container loads the servlet class using normal Java class loading facilities. The loading may be from a local file system, a remote file system, or other network services.
  • After the servlet object is instantiated, the container must initialize the servlet before it can handle requests from clients.
  • Initialization is provided so that a servlet can read persistent configuration data, initialize costly resources (such as JDBC™ API based connections), and perform other one-time activities.
  • The container initializes the servlet instance by calling the init method of the Servlet interface with a unique (per servlet declaration) object implementing the ServletConfig interface.
  • This configuration object allows the servlet to access name-value initialization parameters from the Web application’s configuration information.
  • The configuration object also gives the servlet access to an object (implementing the ServletContext interface) that describes the servlet’s runtime environment.
  • During initialization, the servlet instance can throw an UnavailableException or a ServletException.
  • In this case, the servlet must not be placed into active service and must be released by the servlet container. The destroy method is not called as it is considered unsuccessful initialization.
  • Developers should not assume a servlet is in an active container runtime until the init method of the Servlet interface is called.
  • A servlet should not try to establish connections to databases or Enterprise JavaBeans™ containers when only static (class) initialization methods have been invoked.
  • After a servlet is properly initialized, the servlet container may use it to handle client requests.
  • Requests are represented by request objects of type ServletRequest.
  • The servlet fills out response to requests by calling methods of a provided object of type ServletResponse. These objects are passed as parameters to the service method of the Servlet interface.
  • In the case of an HTTP request, the objects provided by the container are of types HttpServletRequest and HttpServletResponse.
  • It is strongly recommended that Developers not synchronize the service method (or methods dispatched to it) because of detrimental effects on performance.
  • A servlet may throw either a ServletException or an UnavailableException during the service of a request.
  • A ServletException signals that some error occurred during the processing of the request and that the container should take appropriate measures to clean up the request.
  • An UnavailableException signals that the servlet is unable to handle requests either temporarily or permanently.
  • If a permanent unavailability is indicated by the UnavailableException, the servlet container must remove the servlet from service, call its destroy method, and release the servlet instance. Any requests refused by the container by that cause must be returned with a SC_NOT_FOUND (404) response.
  • If temporary unavailability is indicated by the UnavailableException, the container may choose to not route any requests through the servlet during the time period of the temporary unavailability. Any requests refused by the container during this period must be returned with a SC_SERVICE_UNAVAILABLE (503) response status along with a Retry-After header indicating when the unavailability will terminate.
  • The container may choose to ignore the distinction between a permanent and temporary unavailability and treat all UnavailableExceptions as permanent, thereby removing a servlet that throws any UnavailableException from service.
  • Request and response objects should only be used within the scope of the request handling thread. References to the request and response objects should not be given to objects executing in other threads as the resulting behavior may be nondeterministic.
  • The servlet container is not required to keep a servlet loaded for any particular period of time. A servlet instance may be kept active in a servlet container for a period of milliseconds, for the lifetime of the servlet container (which could be a number of days, months, or years), or any amount of time in between.
  • When the servlet container determines that a servlet should be removed from service, it calls the destroy method of the Servlet interface to allow the servlet to release any resources it is using and save any persistent state. For example, the container may do this when it wants to conserve memory resources, or when it is being shut down.
  • Before the servlet container calls the destroy method, it must allow any threads that are currently running in the service method of the servlet to complete execution, or exceed a server-defined time limit.
  • Once the destroy method is called on a servlet instance, the container may not route other requests to that instance of the servlet. If the container needs to enable the servlet again, it must do so with a new instance of the servlet’s class.
  • After the destroy method completes, the servlet container must release the servlet instance so that it is eligible for garbage collection.
  • ServletConfig vs ServletContext
    ServletConfig :
  • One ServletConfig per servlet
  • Used to pass deploy-time info to servlet and configured in deployment descriptor
  • Used to access ServletContext
  • ServletContext:
  • One per webapp
  • Used to access webapp parameters configured in deployment descriptor
  • Application bulletin-board
  • Use to get server info


No comments yet — be the first.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: