Servlet Container session tracking

HTTP is a stateless protocol. For today's web applications, we often need to record the connection between a series of requests from a specific client. There are already many session tracking technologies, but they are not very convenient for programmers to use directly. The Servlet specification defines a simple HttpSession interface to facilitate session tracking by Servlet containers without developers' attention to implementation details. Generally, there are two most common session tracking mechanisms, one is URL rewriting. If the client does not accept cookies, you can use URL rewriting for session tracking.

URL rewriting includes adding data that can be interpreted by containers to the URL path. The specification requires that the session ID must be encoded in the URL path, and the parameter name must be jsessionid. For example: Sessions. The container sends a cookie to the client, which is returned to the server in subsequent requests in the same session. The cookie name for session tracking must be JSESSIONID.

The new session function is SSL session, SSLSecure Sockets Layer, and Secure Socket Layer. It is an encryption technology used by the HTTPS protocol and has a built-in session tracking function, servlet containers can easily use this data to establish session tracking. However, HTTPS is not a protocol that the Servlet must support. Because HTTP is a request-response-based protocol, a session is created only after the client is added to it. When the session trace information is successfully returned to the server to indicate that the session is established, the client adds a session. If the client does not join a session, the next request will not be considered part of the session. If the client does not know the session or the client chooses not to join a session, the session is considered as new. Developers must design their own session processing statuses for their applications, where they do not add sessions, where they cannot join sessions, and where they do not need to join sessions.

The specification requires that HttpSession be valid at the application or Servlet context level. The underlying mechanism for session establishment such as cookie can be shared in context, but for exposed objects, and more importantly, those attributes of the object cannot be shared in the context. For Binding session attributes, any object can be bound to a naming attribute. The bound property object is visible to other servlets that are in the same ServletContext and in the same session.

Some objects must be notified when they are added to or removed from a session. Such information can be obtained through the HttpSessionBindingListener interface of the object. This interface defines two methods to mark or remove a bound to or from a session. The valueBound method is called before the object Passes getAttribute, And the valueUnbound method is called only when the object cannot pass getAttribute.

Because HTTP is a stateless protocol, there is no obvious signal when the client is no longer active, which means there is only one mechanism that can be used to indicate that the client is no longer active: timeout. The default time limit of a session is defined by the Servlet container and can be obtained through getMaxInactiveInterval of HttpSession. developers can also use setMaxInactiveInterval
The Unit returned by these methods is seconds. If the time limit is set to-1, it means that the time will never expire. By calling the getLastAccessedTime method of HttpSession, we can obtain the access time before the current request. When a request in a session is processed by the Servlet context, the session is considered to be accessed.

In addition, it is important to note the semantics of some important sessions.
◆ Multithreading: Multiple request threads may access the same session at the same time. Developers are responsible for synchronizing access to resources in the session in an appropriate way.
◆ Distributed environment: For applications marked as distributed, all requests in the same session can only be processed by a single VM. At the same time, all objects in the HttpSession must implement the Serializable interface. Otherwise, the container may throw IllegalArgumentException and will not throw this exception in jboss_tomcat. However, if there are still unfinished sessions when the server is shut down, then the server will encounter a serialization exception when trying to store sessions, and will attempt to reply to sessions during restart, and exceptions will also occur ).
This restriction means that developers will not encounter the concurrency problems in non-distributable containers. In addition, the container provider can ensure scalability by moving a session object and its content from an active node of the distributed system to another different node of the system.
◆ Client semantics: based on the fact that the cookie or SSL certificate is usually controlled by a web browser and is not connected to a specific browser window, requests sent from all windows of the client application to the container may be the same session. To achieve maximum portability, developers cannot always assume that all the window requests of a specific client are in the same session.

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