[ Team LiB ] 11.1 The Servlet Life
[ Team LiB ] 11.1 The Servlet Life Cycle A CGI has a pretty simple life. When a user makes a request, the Web server runs the CGI program. For a Perl program, this means starting up the Perl interpreter, which then reads the file comprising the program and starts executing instructions, beginning at the top of the file and moving down. For a CGI written in C or C++, the program starts at its main() method, which then may call other procedures, create classes, and so on. In either case, the Web server communicates all the information about the request through a set of variables and data sent to the program’s input. The program generates a response by printing some headers containing the result’s attributes, such as type and length, followed by the result itself. The CGI program then exits, vanishing from system memory as if it had never existed. If the same CGI has many requests, either all at once or one after the other, a new instance of the CGI will be created each time. In principle, servlets could follow the same pattern. A servlet could consist of nothing more than a class with a service() method to handle a request. Each time a request came in, a new instance of the servlet would be created, and its service() method would be called. Inside this method, the class could make calls to get request information, and it could return results by printing the headers and the resulting HTML page, just as a CGI does. This process would save the overhead of loading the class each time but is still very inefficient. The servlet API can best be understood by starting from this model and seeing what improvements could be made. First, it is unnecessary to create a new instance for every request. The Web server needs to create only a single instance and can then call this instance’s service() method for each request. For this to be possible, the service() method could not use any global data or write to a common output stream. If global data were used to hold the request, input would be jumbled if two or more requests came in at the same time. Likewise, if a single output stream were used, the output of multiple simultaneous requests would be intermingled. The solution to this problem is to have the Web server pass in unique instances of objects representing the request and response each time it calls the service() method. This might seem even worse than constructing a new servlet, but in fact doing it this way has advantages. For one thing, the Web server would likely need to do this work anyway, as different requests must be kept isolated from one another. Second, the request and response objects will typically be much simpler than the servlet object, so it will be easier to build them. By the way, if the notion of a request object sounds familiar, it should. This is the same object from which information about the request was obtained in Listing 4.7 and which contains data that is in the request scope. Now that the servlet will be constructed only once, a further optimization can be made. Consider a CGI that uses a database. Each time it is started, it will need to reestablish a connection to the database, because a CGI has no way to hold onto a connection between the time it is shut down and the time it starts up again. However, as a servlet never exits, it needs to open this connection only once. The same is true for many other kinds of initializations, such as building some auxiliary classes or setting some variables to known defaults. This means that all the initialization code can be taken out of the service() method and put into a separate method: init(). The Web server will call the init() method once when the servlet is first loaded, and after that it may call the service() method multiple times. If servlets lasted forever, those two methods would be the only ones needed. However, a servlet may be retired in a number of ways. Sooner or later, the Web server will need to shut down; when it does, it should give all its servlets a chance to clean up after themselves, close database connections, and so on. A servlet might also be replaced by a newer version, in which case the old version should also be given the opportunity to close any resources it Page 198
Note: If you are looking for cheapest and affordable webspace to host and run your servlet application check Astra j2ee hosting services