Describe in detail the management mechanism of session in Tomcat:
1. Session operation during the request process:
Brief description: During the request process, first parse the sessionId information in the request, and then store the sessionId in the parameter list of the request. Then when you get the session from the request, if the sessionId exists, then you will get the session from the session pool based on the Id. If the sessionId does not exist or the session fails, then create a new session and put the session information into the session pool for next use.
(1) SessionId parsing process timing diagram:
Overview: First, the user sends an http request to pass it to Http11Processor, and then passes it to CoyoteAdapter via Http11Processor. The coyoteAdapter is an adapter that adapts the org.apache.coyote.Request encapsulated by the coyote framework to org.apache.catalina.connector.Request (I won't say much about this process, which has been summarized before). After the conversion, the parsePathParameters method will be called to parse the cookie information in the path parameters (because when the cookie is disabled by the browser, the cookie information will be rewrited into the url). First, try to parse the sessionId from the url. Then the parseSessionCookiesId will be called. This is to parse the sessionId from the cookie and store it in the request (parsePathParameters and parseSessionCookiesId methods. During the call process, no obvious XOR logic is seen, that is, both are executed, but isn't there a problem? Think about it, there is actually no problem. If you rewrite the URL to set the sessionId or put it in the cookie, you will only use one of the two methods. Think of this, you will know that there is no problem). The parse to the sessionId and put it in the request. It's OK to parse the logic of SessionId.
The following key codes are posted:
ParsePathParameters method (parsed from rewrite URL):
Ps: The marked parts are parsing variables from the URL and then putting them in the request parameter list.
parseSessionCookiesId method (parsing sessionId from cookies):
Ps: The above tag is to get the sessionId from the cookie. Look at the first tag with a call to SessionConfig.getSessionCookieName (context), here you will get a key of the default sessionId. This key is defined in SessionConfig, and its value is jsessionId:
(2) The process of obtaining session from the request is basically as described above. Then take a look at the process of obtaining session in Servlet:
Overview: appServlet is a Servlet we define ourselves. When we get the session through Reqest, the HttpServletRequest (an interface) that is called is actually RequestFacade (a facade that encapsulates org.apache.catalina.connector.Request), and then RequestFacade will call the getSession method of the real Request. The specific logic of Request is to call the getManger method of the Context container to obtain the Session Manager (details of the session manager are described below). If the SessionId has been parsed, then the findSession method will be called to obtain the corresponding session from the session object pool. Otherwise, if the sessionId does not exist, a session needs to be recreated and placed in the session object pool.
The following key codes are posted:
The getSession method of class RequestFacade:
The getSession method of class Request:
The doGetSession method of class Request:
Ps: The first tag is to obtain session information from the session object pool based on the SessionId, and the second tag is to create a new Session object without parsing the sessionId.
This creates a new session. This point involves the generation of the new sessionId. The logical key code for generating sessionId is defined in the generateSessionId method in the class SessionId Generator:
The above is the process of servlet obtaining session. The following details summarize how tomcat manages session, that is, the knowledge of session manager.
2. Session management mechanism
Session Manager Definition: The Session Manager component is responsible for managing Session objects, such as creating and destroying Session objects.
First, let’s look at a class inheritance structure diagram of the Session Manager (this is the graph of tocmat7.x, and the class inheritance mechanism of tomcat5 is very different from this):
Brief description: The following summarizes each category in turn (refer to the official website information):
(1) Manager: Defines the basic interface associated with a certain container to manage the session pool.
(2) ManagerBase: implements the Manager interface, which provides the implementation of common functions of the Session Manager.
(3) StandardManager: inherits from ManagerBase, the default Session Manager (not specifying configuration, use this by default). It is a non-cluster implementation of tomcat processing sessions (that is, the stand-alone version). When tomcat is closed, the memory session information will be persisted to disk and saved as SESSION.ser, and will be restored when booting again.
(4) PersistentManagerBase: Inherited from ManagerBase, implements and defines the basic functions of session manager persistence.
(5) PersistentManager: inherited from PersistentManagerBase. The main function is to exchange idle session objects (by setting the timeout time) on disk.
(6) ClusterManager: It implements the Manager interface, and you should be guessed by the class name. This is the manager that manages the cluster session and the session manager of the StandardManager stand-alone version above are relative concepts. This class defines the replication and sharing interface of sessions between classes.
(7) ClusterManagerBase: implements the ClusterManager interface and inherits from ManagerBase. This class implements the basic operation of session replication.
(8) BackupManager: Inherited from ClusterManagerBase, an implementation of inter-cluster session replication strategy. There is only one backup node in the session data, and all nodes in the cluster are visible at the location of this backup node. This design gives it an advantage in supporting heterogeneous deployments.
(9) DeltaManager: Inherited from ClusterManagerBase, an implementation of the cluster session replication strategy. Unlike BackupManager, session data will be copied to all member nodes in the cluster, which requires that all nodes in the cluster must be isomorphic and the same application must be deployed.
Supplement: Let's summarize it in detail below. There is a member variable Store in the PersistentManagerBase class:
The storage strategy of the persistent session manager is defined by this Store object. The class inheritance structure of this Store is as follows:
Brief description: The interface Store and its examples provide a set of storage strategies for the session manager. The store defines the basic interface, and the StoreBase provides the basic implementation. The policy implemented by the FileStore class is to store the session in a file specified in the directory with setDirectory() and end with .session. The JDBCStore class stores the Session into the database through JDBC. Therefore, it is necessary to use JDBCStore. You need to call the setDriverName() method and the setConnectionURL() method respectively to set the driver name and connection URL.
3. Tomcat session-related configuration
Summarize the configuration and settings related to session from two levels. First of all, from the configuration file level, session has an expiration time, and the default expiration time is defined in $catalina_home/conf/web.xml. The specific default configuration is as follows (the default expiration time is 30min, that is, there is no access in 30min, and the session expires):
Another point is that if session management is not configured, StandardManager is used by default. However, if you want to configure it, you can specify it in $catalina_home/conf/context.xml (from this configuration, you can see that the session manager is associated with the context container, which means that each web application will have a session manager). The specific configuration is as follows:
Tomcat7.x defaults to the configuration of this manager. If the PersistentManager you want to specify is the default manager, you can specify it like this:
In fact, after seeing this, I discovered that the session manager or Store storage policy can be customized as long as the relevant interface is implemented. It's OK to write a configuration yourself here.
In addition, let’s summarize from the code level: some configuration information of session is written in the code, for example, the SessionConfig class defines some session setting information. The name of Session in the cookie is JSESSION. When Session is placed in the path through URL rewriting, the name of the key value is jsessionids. The specific code is as follows:
Another point is that the default specified length of sessionId is 16 bytes, which is specified in the SessionIdGenerator:
OK, so much is summarized about the default configuration.
The above is all the content of this article. I hope it will be helpful to everyone's learning and I hope everyone will support Wulin.com more.