Deep understanding and improvement of Jsp/servlet session management mechanism

In Web server-side programming, session state management is an important issue that must be considered frequently. This paper analyzes the session management mechanism of Jsp/servlet and the problems it faces, and then proposes an improved session management method.

First, the servlet session management mechanism

HTTP is a stateless protocol, according to the design. It means that the Web application does not know about the information previously requested by the same user. One way to maintain session-state information is to use the session-tracking functionality provided by the servlet or JSP container. The Servlet API specification defines a simple httpsession interface through which we can easily implement session tracking.

The HttpSession interface provides a way to store and return standard session properties. Standard session properties, such as session identifiers, application data, and so on, are saved in the form of a "name-value" pair. In short, the HttpSession interface provides a standard way to save objects to memory and extract them from the same user's subsequent request. The method of saving data in a session is setattribute (string s, Object o), and the method of extracting the original saved object from the session is getattribute (string s).

In the HTTP protocol, there is no explicit termination signal when the user is no longer active. For this reason, we don't know if the user is going to return again, and if there is no way to solve the problem, a large number of HttpSession objects will accumulate in memory.

To this end, the servlet uses the "time-out limit" method to determine whether the user is still accessing: If a user does not issue a subsequent request within a certain amount of time, the user's session is invalidated and his HttpSession object is released. The default time-out interval for a session is defined by the servlet container. This value can be obtained by means of the Getmaxinactiveinterval method, modified by the Setmaxinactiveinterval method, in which the timeout time is measured in seconds. If the timeout value of the session is set to-1, the session never times out. The servlet can obtain the last access time before the current request through the Getlastaccessedtime method.

To get the HttpSession object, we can call the GetSession method of the HttpServletRequest object. In order to maintain session state correctly, we must invoke the GetSession method before sending any reply.

User sessions can be either invalidated by manual method or automatically invalidated. A voided session means that the HttpSession object and its data are deleted from memory. For example, if the user no longer sends a request within a certain period of time (the default 30 minutes), the Java Web server automatically invalidates his session.

The SERVLET/JSP session tracking mechanism has certain limitations, such as:

· The session object is saved in memory and occupies a considerable amount of resources.

· Session tracking relies on cookies. Some users have turned off cookies for a variety of reasons, especially for security reasons.

· Session trace to use the session identifier created by the server. 　　In the context of multiple Web servers and multiple JVMs, the Web server does not recognize session identifiers created by other servers, and session tracking mechanisms do not work. To understand the session-tracking mechanism in depth, we must first understand how the session works in the Servlet/jsp container.

Second, session identifier

Whenever a new user requests a JSP page that uses a HttpSession object, the JSP container sends a special number to the browser in addition to sending back the answer page. This particular number is called the session identifier, which is a unique user identifier. Thereafter, the HttpSession object resides in memory, waiting for the same user to call its method again when it returns.

On the client side, the browser saves the session identifier and FU Fa the session ID to the server in each subsequent request. The session identifier tells the JSP container that the current request is not the first request made by the user, and the server has previously created the HttpSession object for that user. At this point, the JSP container no longer creates a new HttpSession object for the user, but instead looks for a HttpSession object with the same session identifier, and then establishes the association between the HttpSession object and the current request.

The session identifier is sent as a cookie between the server and the browser. What if the browser doesn't support cookies? At this point, subsequent requests to the server will not have a session identifier. As a result, the JSP container considers the request to be from a new user, and it creates a HttpSession object, and the previously created HttpSession object still resides in memory, but the user's previous session information is lost.

In addition, the SERVLET/JSP container recognizes only the session identifiers it creates itself. If the same Web application is running on multiple servers on a Web farm (Web farm), you must have a mechanism in which a request from the same user is always directed to the server that handles the first request for that user.