Servlets typically have the operating cycle, as shown in Figure 26-5.
The sequence of events in a servlet's lifetime is:
-
The servlet container starts up, and at some point constructs an instance of the servlet and calls its
init()method. Theinit()method is only called once. Not once per request, not once per session, but once at the beginning of the servlet's lifetime. Theinit()method is a good place to put code to open a database connection. -
Unlike, say, a GUI, there is no background thread always running code in the servlet. The servlet instance object just stays ready in memory, waiting for a request. This makes servlets very efficient. Eventually, a request comes to the web server, and the web server passes the request to the servlet container.
-
The servlet container instantiates a new thread to process the request. Note that the container does not instantiate a new servlet object. The newly created thread representing the request calls the
doPost()method (or whatever is appropriate for this request) of the existing instance of your servlet. The servlet can access a database, the filesystem, other servlets, etc. It creates the HTTP response, which the container returns to the client. Thread-per-request makes servlets scalable and high performance. -
Repeat steps 2 and 3 for each request. Eventually the web server will be requested to shut down. At that point, the servlet's
destroy()method is called. Then it is a candidate for garbage collection and finalization. A servlet instance will also be destroyed if you have set things up so that newer versions of a servlet are loaded automatically.
Servlets typically run on multithreaded servers and instantiate a new thread for each incoming request. This is the usual way that servers process incoming requests on a socket—create a new thread for each request for service. The use of threads means that two requests might be executing in your servlet code at the same time. Your code will need to synchronize access to any resources that are shared. This will include resources like instance variables, database connections, and static data. If you don't properly synchronize access to instance data, you will run into trouble with data race bugs.
Consider a servlet that accesses a database and puts data in an instance variable of the servlet. The servlet specification stipulates that you get a new thread for each invocation of a servlet, but not a new instance of the servlet object.
If two requests come in together and you are unlucky with scheduling, it could happen that request A gets its data out of the database, but it is overwritten in the instance variable with B's data from the database before A can use it. Then the servlet returns B's data to both A and B, confusing everyone. Chapter 14, “Advanced Thread Topics,” explains synchronization in more detail.
There used to be an alternative to making your servlet thread safe. You were able to declare that your servlet implemented javax.servlet.SingleThreadModel. This has now been deprecated and should no longer be used.
There is really not much more to servlets than we have now seen. The topics outside the scope of this chapter are cookies, setting a session, security, filtering, and redirecting the request to another servlet.
A cookie is a morsel of tasty data that a server sends back to the client and can retrieve on demand. It allows the server to retain some state information for each of its clients. The information is typically something like, “what pages has the user seen?” or “has this user given the password yet?” Unless configured otherwise, the client send its cookie tokens back to the web server that they originally came from, with every web page request to that server.
A session is a way for the server to keep track of a user across a series of page requests. You would use a session to conduct an entire e-commerce transaction, with all the different pages for choosing goods, submitting credit card numbers, and so on. Cookies are often used to maintain session information. Readers who want to know more about these two matters can look at the examples in the sample code that comes with Tomcat. Start Tomcat running and then browse the URL //127.0.0.1:8080 to see these pages.
All of these topics, including filtering and redirecting, are covered at length in the Servlet version 2.4 Specification, which can be downloaded from the Sun website. Although they call it a specification, and it's more than 200 pages long, it's easy to read and worth taking a look at. You can find it at java.sun.com/products/servlet/index.html.