| There are too many misunderstandings about httpsession. It was originally a very simple question. How can it be so complicated? Let's talk about my understanding: A session is a series of communications between a user and the server. The server has the ability to distinguish different users. A session starts when a user sends the first request to the server, and ends when the user explicitly ends or the session times out.
The working principle is as follows:
1. When a user sends the first request to the server, the server creates a session for the user and creates an ID number for the session;
2. All subsequent requests of this user should include this ID number. The server verifies the identification number to determine which session the request belongs.
This mechanism does not use IP addresses as identifiers because many machines access the Internet through proxy servers and cannot distinguish each machine.
There are two methods for implementing the session ID: Cookie and URL rewriting. Httpsession usage
Let's take a look at how sessions are defined and operated in the API.
When you need to create a session for the client, the servlet container creates an httpsession object. Information related to this session is stored. Therefore, the number of httpsession objects in a servlet when there are different user connections.
The Mechanism is as follows:
1. Extract the httpsession object from the request;
2. add or delete attributes in httpsession;
3. Disable or invalidate httpsession as needed. There are two overload methods in the request to obtain the httpsession object.
Httpsession getsession (Boolean create)/getsession (); extracts the httpsession object if it is not automatically created. After obtaining the httpsession object, we need to use some methods of httpsession to set and change some parameters. For example:
Void setattribute (string name, object value );
Object getattribute (string name );
Void removeattribute (string name ); In the javax. servlet. http package, four session listener interfaces and two associated session events are defined. They are:
Httpsessionattributelistener and httpsessionbindingevent;
Httpsessionbindinglistener and httpsessionbindingevent;
Httpsessionlistener and httpsessionevent;
Httpsessionactivationlistener and httpsessionevent. Their Inheritance relationships are:
The parent class of all four interfaces is Java. util. eventlistener;
Httpsessionevent extends java. util. eventobject;
Httpsessionbindingevent extends httpsessionevent. The following details:
Httpsessionattributelistener
When a property in a session is added, changed, or deleted, it is notified. This interface is described in the previous section, mainly in the other three. Httpsessionbindinglistener
When a class that implements httpsessionbindinglistener is added to or removed from httpsession, httpbindingevent events are generated and received by the class itself.
This interface defines two methods:
Void valuebound (httpsessionbindingevent E );
Void valueunbound (httpsessionbindingevent E );
When multiple classes that implement httpsessionbindinglistener are added to httpsession, all kinds of methods are only interested in this class and will not ignore the addition of other classes.
Even different instances of the same category do not care about each other ). We can see that the first two interfaces both respond to the httpsessionbindingevent event, but the mechanism is different.
Httpsessionattributelistener is registered in Web. xml. The servlet container creates only one instance to serve any servlet that adds attributes to the session. The object that triggers the event is all instances that can be converted to the object.
Httpsessionbindinglistener does not need to be registered in Web. xml. It creates an instance with new in each Servlet and is only interested in adding (or removing) the instance to/from the session. The object that triggers the event is only itself. Httpsessionlistener
Interested in session creation and cancellation. You need to register in Web. xml.
There are two methods:
Void sessioncreated (httpsessionevent SE );
Void sessiondestroyed (httpsessionevent SE );
Using it, we can easily create a class to count sessions.
Maybe we will simply consider using the sessiondestroyed method to clear some work after the session ends. However, please note that when this method is called, the session is over and you cannot extract any information from it. Therefore, we need to find another path.
One common method is to use the httpsessionbindinglistener interface. Add an attribute when the session is created, and delete the attribute before the session ends. This triggers the valueunbound method, all session cleanup operations can be implemented in this method. Httpsessionactivationlistener
When the session is cross-JVM in a distributed environment, the object implementing this interface is notified. There are two methods:
Void sessiondidactivate (httpsessionevent SE );
Void sessionwillpassivate (httpsessionevent SE ); 1. the HTTP protocol itself is in the "connection-request-response-close connection" mode and is a stateless protocol (HTTP is only a transmission protocol );
2. Cookie specification is used to add status tracking for HTTP (if you need to be precise, read the related RFC carefully), but it is not the only method;
3. The so-called session refers to the state information (data) of the interaction process between the client and the server. How to define the State and how long the life cycle is, this is the application itself;
4. In the B/S computing model, the computation is completed on the server, and the client only has simple display logic. Therefore, session data should be transparent to the client and should be controlled by the server; session data should be either stored on the server (httpsession ), either pass between the client and the server (cookie or URL rewritting or hidden input );
5. Due to the stateless nature of HTTP itself, the server cannot know that the client sends successive requests from one customer. Therefore, when using the server httpsession to store session data, each client request should contain a session ID (SID, JSESSIONID, and so on) to inform the server;
6. The advantage of saving session data on the server (such as httpsession) is that it reduces the length of HTTP requests and improves network transmission efficiency; the opposite is true for storing session information on the client;
7. There is only one way to store client sessions: cookie (because URL rewritting and hidden input cannot be persistent, not counting, it can only be used as a way to exchange session IDs, that is, a method of session tracking ), the server-side approach is basically the same: the container has a Session Manager (such as Tomcat's org. apache. catalina. class in the session package), provides session lifecycle and persistent management, and provides APIs to access session data;
8. Using server or client session storage depends on the actual situation of the application. Generally, users are not required to register and log on to public service systems (such as Google) using cookies for client session storage (such as Google's user preference settings), while user-managed systems use server-side storage. The reason is obvious: the only system that can identify the user without user logon is the user's computer. If you change to a machine, you do not know who the user is. The session storage on the server is useless; A user-managed system can use user IDs to manage user personal data and provide any complicated personalized services;
9. Session storage on the client and server differ in performance, security, cross-site capabilities, programming convenience, and other aspects. The advantages and disadvantages of session storage are not absolute (for example, theserverside claims that it does not use httpsession, therefore, the performance is good. Obviously, it is inefficient to retrieve user preferences in the server database in a system with hundreds of millions of users, the Session Manager consumes a lot of memory and CPU time no matter what data structures and algorithms it uses. However, when using cookies, session data does not need to be retrieved or maintained at all. The server can be stateless, of course efficient );
10. The so-called "session cookie" is simply a cookie that does not explicitly specify the validity period. It is valid only for the current browser process and can be cleared by subsequent set-Cookie operations. |
