The management mechanism of the session in Tomcat _java

Detailed description of the management mechanism for the session in Tomcat:

1. Session operation during request:

Description: The SessionID information in the request is first resolved during the request process, and then the SessionID is stored in the parameter list of the requests. Then, when the session is fetched from request, if there is a SessionID then the session is obtained from the session by ID, if the SessionID does not exist or the session fails, Then a new session is created and the session information is placed in the session pool for next use.

(1) SessionID analytic process sequence diagram:

Overview: First, the user sends an HTTP request to the Http11processor, Encapsulated via Http11processor parsing in Org.apache.coyote.Request and then passed to Coyoteadapter,coyoteadapter is an adapter that will coyote the framework of the encapsulated Org.apache.coyote.Reque St rationing Org.apache.catalina.connector.Request (this process is not much said, summarized before), after the conversion will call the Parsepathparameters method to resolve the path parameters in the cookie information (because when the cookie is banned by the browser When the cookie information is rewritten into the URL, try parsing the SessionID from the URL first. The PARSESESSIONCOOKIESID is then invoked, which is parsing the SessionID from the cookie to the request (Parsepathparameters and Parsesessioncookiesid method, in the call process , there is no obvious difference or logic, that is, both are implemented, but is this not a problem? Think of the fact that there is no problem, URL rewrite settings SessionID or put in a cookie to pass over, the two ways will only use one, think of this to know that there is no problem with the resolution to SessionID on the request inside. Parsing SessionID's logic is OK.

The key code is posted below:

Parsepathparameters method (parsed from the rewrite URL):

Ps: The marked part is to parse out the variable from the URL and put it in the request parameter list.

Parsesessioncookiesid method (parse out SessionID from cookie):

Ps: The mark above is to get the SessionID from the cookie. See the first tag has a sessionconfig.getsessioncookiename (context) call, where you get a default SessionID key that is defined in Sessi In Onconfig, the value is Jsessionid:

(2) The process of getting the session from the request is basically as described above. Then take a look at the servlet's process of getting session:

Overview: Appservlet is a servlet that we define ourselves, and when we get the session through Reqest, In fact the call of this httpservletrequest (is an interface) is actually Requestfacade (encapsulates a org.apache.catalina.connector.Request façade), and then Requestfacade will invoke the real requ The GetSession method of est. The specific logic of the request is to invoke the Getmanger method of the context container to get the Session Manager (Session Manager details below), and then if SessionID has been parsed, Then the Findsession method is invoked to get the corresponding session from the session object pool, whereas if SessionID does not exist, a session needs to be recreated and placed in the Session object pool.

The key code is posted below:

GetSession methods for class Requestfacade:

The GetSession method of the class request:

The Dogetsession method of the class request:

Ps: The first token is based on SessionID from the session object pool to get session information, the second tag is to create a new session object without parsing to SessionID.

This creates a new session where the point involves the creation of a new SessionID, and the logical key code to generate SessionID is defined in the Generatesessionid method in the class Sessionidgenerator:

The above is the servlet to obtain the session process, the following specific summary of how Tomcat is to manage the session, that is, Session Manager knowledge.

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 look at a class inheritance chart of the session manager (this is the tocmat7.x diagram, the TOMCAT5 class successor mechanism is very different from this):

Summary: Below summarize each class (reference official website information) in sequence:

(1) Manager: Defines the basic interface that is associated with a 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 the Managerbase,tomcat default session manager (does not specify the configuration, by default this), is the Tomcat processing session's non-clustered implementation (also says is the stand-alone version), when Tomcat closes, Memory session information is persisted until the disk is saved as Session.ser and resumed when it is restarted.

(4) Persistentmanagerbase: Inherits from Managerbase, implements and defines the basic function of the session manager persistence.

(5) Persistentmanager: Inherited from Persistentmanagerbase, the main implementation of the function is the idle session object (through the set timeout time) swap to disk.

(6) Clustermanager: Implement the manager interface, through the class name should be able to guess, this is the management of the cluster session Manager and the above Standardmanager stand-alone version of the session manager is a relative concept. This class defines a replication shared interface for sessions between class clusters.

(7) Clustermanagerbase: Implements the Clustermanager interface, inherits from the Managerbase. This class implements the basic operation of session replication.

(8) Backupmanager: Inherits from the Clustermanagerbase, one kind of realization of the session replication strategy between the clusters, the conversation data has only one backup node, the backup node's location is visible to all nodes in the cluster. The advantage of this design is that it supports heterogeneous deployments.

(9) Deltamanager: Inherits from the Clustermanagerbase, the cluster constructs the session to replicate the strategy the realization, and Backupmanager is different, the conversation data can replicate to all member nodes in the cluster, this also requires that all nodes in the cluster must be isomorphic, The same application must be deployed.

Add: The following is a specific summary of the Persistentmanagerbase class has a member variable store:

The storage strategy for the persistence Session Manager is defined by this store object, and the store's class inheritance structure is as follows:

Description: The interface store and its instance are a set of storage policies for the session manager, the store defines the basic interface, and Storebase provides a basic implementation. Where the Filestore class implements a policy that stores the session in a file that is specified in Setdirectory () and ends with a. session. The Jdbcstore class is where the session is stored in the database through JDBC, so you need to use Jdbcstore, and you need to call the Setdrivername () method and the Setconnectionurl () method separately to set the driver name and connection URL.

3. Tomcat-related configuration

Summarize the session-related configuration and settings from two levels. First, from the configuration file level, the 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 is 30min, that is, 30min is not accessed, the session expires):

Another point is session management if you do not configure the default use of Standardmanager, but if you want to configure the $catalina_home/conf/ Context.xml, where you can see from this configuration that the session manager is associated with the context container, and that each Web application has a session manager, the specific configuration is as follows:

tomcat7.x default this manager's configuration is commented out. If the persistentmanager you want to specify is the default manager, you can specify this:

Actually see this also found that, in fact, the session manager or store storage strategy, as long as the implementation of the relevant interface, can be customized. Write a configuration of your own here is OK.

In addition, a summary from the code level: Some of the configuration information of the session is written dead in the code, such as Sessionconfig This class defines some session settings information. The name of the session in the cookie is jsession. When the session is placed in path by URL rewrite, the name of the key value is Jsessionids, and the specific code is as follows:

And one thing is SessionID the default length specified is 16 bytes, which is specified in Sessionidgenerator:

Well, the default configuration is summed up so much first.

The above is the entire content of this article, I hope to help you learn, but also hope that we support the cloud habitat community.