Persistent Session manager for Tomcat sessions

The standard Session manager mentioned earlier already provides the underlying session management functionality, but does not do enough in terms of persistence, or in certain scenarios, such as storing a session as a file or database in a storage medium, which is not possible with the standard Session manager. Another session manager is designed to persist the session manager.

Before you analyze the persistence Session manager, you might want to learn about another abstract concept session storage store, which is introduced to make it easier and easier to implement a variety of session storage methods. The most important operation as a storage device is read and write operations, reading is to load the session from the storage device into memory, while writing writes the session to the storage device, so defines two important methods load and save correspond to it. filestore and jdbcstore as long as the extended Store interface each implements the load and the save method can be implemented as a file or database as a separate storage session. the UML class diagram looks like this:

1)Filestore

The

File storage device provides a file-saving session that, when written, generates a file for each session to hold information about the session, with each session file name defined as sessionid+ The format of the . session, for example, "326257da6db76f8d2e38f2c4540d1dea.session " Span style= "font-family: the song Body;" ", while the directory path is stored by servletcontext.tempdir "%catalina_home%/work/catalina/localhost/web ' name/", which is actually" Tomcat +work+enginename+hostname+ Contextname ". So if there are 10,000 sessions there will be 10,000 session files. For ease of operation write directly using jdk Bring Your own java.io.objectoutputstream serializable interface.

Similarly, loading a session is done by passing in a sessionId, assembling the file name into the sessionid+". Session" format to find the corresponding session file and then using the JDK Bring your own Java.io.ObjectInputStream loading the Session object into memory is actually a deserialization process.

The configuration file can be configured as follows:

<store classname= "Org.apache.catalina.session.FileStore" directory= "Sessiondir"/>

If directoryis configured, the directorywill be stored as "%catalina_home%/work/catalina/localhost/web ' Name/sessiondir", Of course, if configured as an absolute path, the absolute path you configure is the storage directory.

Using Filestore as a storage device appears to be quite inefficient on file operation IO Because each file operation is open - action - off, no optimizations are used, so Tomcat is likely to be a point that affects overall performance when it chooses to use this approach, and must be well tested for performance.

2)Jdbcstore

JdbcThe storage device provides a database as a session, the backend can be any vendor's database, as long as there is a corresponding database driver. Since the data must be stored in the database first to create a session table, the structure of the table should beTomcatwith theMySQLthe parties agreed, for exampleTomcatThe default table name is"Tomcat$sessions", table field in total6one, respectively, for"App", "id", "data", "valid", "maxinactive", "lastaccess",appfields are used to distinguish whichWebApplication,IDfield is the session ID,Datafield is used to hold the Session object byte string,validfield indicates whether this session is valid,maxinactivefield indicates the maximum time to live,lastaccessThe field represents the last access time. One of the things to note isDatafield, because its size directly affects the size of the session object, it needs to be set according to the actual type, if it isMySQLYou can consider setting theBlob(65k) orMediumblob(16m).

In this way, the loading and saving of the session is translated into read and write operations to the database, and the logic to get the database connection is to determine whether there is a data source in the Tomcat container, and if so, get a connection directly from the data source. However, if not, you will be driven to create the connection, it is important to note that the connection obtained from the data source will be put back into the data source after use, but the connection created by the driver will not be closed, this is very well understood, because the data source is a pool, re-get connections quickly, The re-creation of a self-built connection typically requires a second level of consumption, which can cause significant problems.

The following example configures a JDBC storage device as a MySQL database:

<store classname= "Org.apache.catalina.session.JDBCStore"

Connectionurl= "Jdbc:mysql://localhost:3306/web_session?user=user&password=password"

Drivername= "Com.mysql.jdbc.Driver"

Sessionappcol= "App_name"

Sessiondatacol= "Session_data"

Sessionidcol= "session_id"

Sessionlastaccessedcol= "Last_access"

Sessionmaxinactivecol= "Max_inactive"

Sessiontable= "Tomcat_sessions"

Sessionvalidcol= "Valid_session"/>

Some of the properties of the session table and its fields can be configured without having to configure it directly with the Tomcat default, but the driver and connection URL must be configured.

There is no apparent IO performance issue from the surface when using jdbcstore as a storage device , because it uses a data source to get the connection and is a pooling technology, even if there is no data source and a long-term connection mode is used. The general data stream is not very large and there is no performance problem.

After the entire introduction of the storage device store and then look at the persistent Session manager, in fact, the persistent Session Manager is the main implementation of three kinds of logic for the session to persist, ① when the number of session objects exceeds the specified threshold, the exceeded session object is converted (saved to Store and delete this object in memory) to the Store ② This Session object when the session is idle for more than the specified threshold, ③ this session when the session is idle longer than the specified threshold (save to Store and memory exists in this object).

The

Implementation of the above logic simply iterates through all the session collections, passing the qualifying pass store save. Because some sessions are persisted to store Span style= "FONT-FAMILY:CALIBRI;" >id store Span style= "font-family: the song Body;" > find.

Here is an example of a configuration that transfers a session with more than a few minutes of idle time to store until the number of sessions is controlled at more than a few minutes of idle sessions are swapped out to store, more than Seconds of idle sessions are backed up to the store.

<manager classname= "Org.apache.catalina.session.PersistentManager"

maxactivesessions= "1000"

minidleswap= "60"

maxidleswap= "120"

Maxidlebackup= ">"

<store classname= "Org.apache.catalina.session.FileStore" directory= "Sessiondir"/>

</Manager>

So It is quite clear that the implementation mechanism of the persistent session manager after two stores has been learned, in fact, is to provide two ways to save the session and provide the operation to manage these sessions, it improves the Tomcat Improved fault tolerance for state-related aspects of processing.

Like Java can make a friend:

Copyright NOTICE: This article for Bo Master original article, without Bo Master permission not reproduced.

Persistent Session manager for Tomcat sessions