| Previous | Table of Contents | Next |
If the servlet is executing long-running operations, it may be told to destroy before all of the operations are complete. This means that as the developer, if you are using multithreaded servlets, you should plan for destroy to be called during a long-running operation. One possible mechanism for dealing with this situation is to have destroy set a flag and have the servlet check whether the flag is on at the end of each request. If the flag is true and the request is the last one, the servlet will clean up its resources. Put simply, the servlet might not clean up in the destroy method, but instead in its service method, after checking whether destroy was called.
| Table 7.2 UnavailableException Methods | |
| METHOD | DESCRIPTION |
|---|---|
| public boolean isPermanent() | Returns true if the servlet requires administrative intervention before becoming available. |
| public Servlet getServlet() | The servlet in question. |
| public int getUnavailableSeconds() | The number of seconds that the servlet expects to be unavailable. |
Keep in mind that most servlets should perform reasonably short operations, in order to provide user responsiveness. In those cases, it is not necessary to plan too extensively around destroy getting called too early. Servlets that do not require open resources, created in init and closed in destroy, may not even need to implement the method.
Once a servlet is initialized, the key method used to interact with it is:
public void service(ServletRequest request,
ServletResponse response) throws ServletException
This service method is made up of a simple interface that takes information about the request and an object that encapsulates the response. Whenever a request arrives at the server for a particular servlet, the server wraps up information about the request, creates a response object to contain information relevant to the response, and calls service. The service method uses a ServletException, a special type of Exception object, to indicate when an exception has occurred.
A simple example of the service method follows in the form of the classic HelloWorld program. The results of accessing this servlet are pictured in Figure 7.1. The bold code shows that the service method is sent a request object containing the details of the client request and a response object used to return values to the client. The method writes Hello World to a Web page on the client browser.
import java.io.*;
import java.util.*;
import javax.servlet.*;
import javax.servlet.http.*;
public class HelloWorldServlet extends GenericServlet
{
public void service(ServletRequest request,
ServletResponse response)
throws ServletException,
IOException
{
PrintWriter out;
response.setContentType(text/html);
out = response.getWriter();
out.println(<HTML><HEAD><TITLE>);
out.println(Hello World);
out.println(</TITLE></HEAD><BODY>);
out.println(<H1>Hello World</H1>);
out.println(</BODY></HTML>);
out.close();
}
}
Other servlets may have similar versions of service or implementations that are more complex. The important point is that service is the Web servers interface to the servlet. You, as the servlet writer, can do anything you want, as long as Java supports it, inside the service method. This could include using JNDI to look up the e-mail address in an LDAP directory or finding inventory items in a database through JDBC.
The next step in implementing a servlet is to decide if it will support multithreading. This is an important decision for the programmer. If you decide not to support multithreaded access to the servlet, the servlet should implement the SingleThreadModel interface. This interface defines no methods and is instead a typing mechanism. Servlets marked with SingleThreadModel are guaranteed by the server to be accessed only by a single thread. When a servlet implements SingleThreadModel, it is really saying that it doesnt want the service method called from more than one thread.
Figure 7.1 Hello World.
Several issues go into the decision of servlet multithreading:
Keep in mind that supporting multiple threads is more flexible than marking the servlet as single threaded. Marking it single threaded is certainly easier on the program design, but it is more limiting in your program design. We will discuss multithreaded servlets in detail in the upcoming section, Multithreaded Servlets.
Each call to service includes an object that implements the ServletRequest interface. This object stores information about the request made by the client to the servlet. Request information comes in three forms. First, there is information about the client/server environment. Second, there is raw access to the client request. Third, there are processed versions of the client request. The difference between the last two types of information is very easy to describe in the context of a servlet that hosts an HTML form. When the form is submitted, the client sends an encoded string containing the name and value of each form element. The servlet can access this string directly (the second form), or it can access the values of each form element by their names (the third form).
All of the methods for ServletRequest are listed in Table 7.3.
Servlets that are designed to respond to HTML form requests will normally use the getParameterValue and getParameterValues methods to obtain information about the form request. Servlets that expect a string of text to be supplied should use getReader to obtain an appropriate reader; servlets that expect binary input should use getInputStream to access data from the request.
| Previous | Table of Contents | Next |