Detailed description of Servlet instances

Servlet has a good life cycle definition, including how to load, instantiate, initialize, process client requests, and how to be removed. The lifetime is expressed by the init, service, and destroy methods of the javax. Servlet. Servlet interface.

1. Loading and instantiation

The container is responsible for loading and instantiating a Servlet. Instantiation and loading can occur when the engine is started, or when the container needs the Servlet to request services from the customer.
First, the container must first locate the Servlet class. If necessary, the container may use a common Java class loading tool to load the Servlet from the local file system, it can also be a remote file system or other network services. After the container loads the Servlet class, it will instantiate an instance of the class. Note that multiple instances may be instantiated. For example, a Servlet class has multiple definitions due to different initial parameters, or the Servlet implements SingleThreadModel and the container generates an instance pool for it.

2. Initialization

After the Servlet is loaded and instantiated, the container must initialize it before it can process client requests. The initialization process mainly reads permanent configuration information, expensive resources such as JDBC connections) and other tasks that only need to be executed once. Call its init method and pass it a unique Servlet definition.) The ServletConfig object completes this process. The configuration object passed to it allows the Servlet to access the name-value pair name-value in the configuration information of the container. This configuration object also provides Servlet with methods to access specific objects that implement the ServletContext interface. This object describes the Servlet runtime environment.

2.1 initialize error handling
During initialization, the Servlet instance may fail to provide valid services by throwing an UnavailableException or ServletException exception. If a Servlet throws such an exception, it will not be put into a valid service and should be immediately released by the container. In this case, the destroy method is not called because the initialization is not completed successfully. After a failed instance is released, the container may instantiate a new instance at any time, the only exception to this rule is that if the failed Servlet throws an UnavailableException and the exception specifies the minimum invalid time, then, the container will try to create a new instance only after the specified time limit.

2.2. Tool Factors
When tool Note: according to my understanding, this tool may be some check tools of the application server, usually used to verify the validity and integrity of the Application) load and introspect) a web application, it may load and save classes in the application. This action will trigger the static initial methods of those classes to be executed. Therefore, the developer cannot assume that the Servlet's init method is in the active container running status as long as it is called ). As an example, this means that the Servlet cannot be in its static class. When the initialization method is called, it tries to establish a database connection or connect to the EJB container.

3. Process requests

After the Servlet is properly initialized, the container can use it to process requests. Each request is represented by an object of the ServletRequest type, and the Servlet uses the ServletResponse to return the request. These objects are passed to the Servlet as parameters of the service method. In the case of HTTP requests, the container must provide the specific implementation of HttpServletRequest and HttpServletResponse that represent the requests and responses. Note that the container may create a Servlet instance and put it in the waiting status, but this instance may not process any requests during its lifetime.

3.1 Multithreading
The container may send requests from multiple clients to the service method of an instance at the same time, which means that the developer must ensure that the compiled Servlet can handle concurrency issues. If the developer wants to prevent such default behavior, he can let the Servlet he wrote implement SingleThreadModel. This class ensures that only one thread is executing the service method at a time. The container can meet this requirement by queuing requests or maintaining a Servlet instance pool. If the Servlet is a part of a distributed application, the container may maintain an instance pool in each JVM where the application is distributed. If the developer uses the synchronized keyword to define the service method (or doGet and doPost), the container will queue the request for processing, which is required by the underlying java runtime system. We strongly recommend that developers do not synchronize service methods or service methods such as doGet and doPost in HTTPServlet.

3.2 handle exceptions in the request
The Servlet may throw a ServletException or UnavailableException when providing services for requests. ServletException indicates that an error occurs during request processing. The container should clear the request using the appropriate method. UnavailableException indicates that the Servlet cannot process the request, which may be temporary or permanent. If UnavailableException indicates that it is permanent, the container must remove the Servlet from the service, call its destroy method, and release its instance. If the request is temporary, the container can choose not to send any request to the temporarily unavailable period specified in the exception information. During this time period, the rejected request must use SERVICE_UNAVAILABLE (503) to return a response and should carry the Response Header of Retry-After later. This indicates that the service is unavailable only temporarily. The container can also choose not to distinguish between temporary and permanent unavailability, and treat all as permanent and remove the Servlet that throws an exception.

3.3 thread security
Developers should pay attention to the request and response objects implemented by the container. Note: HttpServletRequest and HttpServletResponese implemented by the container are not guaranteed to be thread-safe, this means that they can only be used within the scope of the request processing thread. These objects cannot be referenced by other execution threads because the referenced behavior is uncertain.

4. Service Termination

The container is not required to save a loaded Servlet for a long time. Therefore, a Servlet instance may only survive for several milliseconds in the container, of course, it may also be another longer time, but it will definitely be shorter than the container's lifetime.) when the container decides to remove it, the reason may be to save the memory resources or close the memory itself ), then it must allow the Servlet to release any resources it is using and save any permanent State. This process is achieved by calling the destroy method ). Before the container can call the destroy method, it must allow the threads that are being executed in the service method to finish or execute the time period defined by the server before the container calls destroy ). Once the destroy method is called, the container will no longer send any request to the instance. If the container needs to use the Servlet again, it must create a new instance. After the destroy method is complete, the container must release the Servlet instance so that it can be recycled.

1. Introduction to functions of Servlet 2.4
2. Introduction to multiple Servlet Interfaces
3. Interface introduction-Servlet Context
4. Servlet Registration Method
5. Introduction to Servlet containers