The Manager Component
Table of Contents
Introduction
The Manager element represents the session manager that will be used to create and maintain HTTP sessions as requested by the associated web application.
A Manager element MAY be nested inside a Context component. If it is not included, a default Manager configuration will be created automatically, which is sufficient for most requirements, — see Standard Manager Implementation below for the details of this configuration.
Attributes
Common Attributes
All implementations of Manager support the following attributes:
| Attribute | Description | 
|---|---|
| className | Java class name of the implementation to use.  This class must
        implement the  | 
| maxActiveSessions | The maximum number of active sessions that will be created by
        this Manager, or  When the limit is reached, any attempt to create a new session
        (e.g. with  | 
| notifyAttributeListenerOnUnchangedValue | If an attribute is added to the session and that attribute is already
        present in the session under the same name will any
         | 
| notifyBindingListenerOnUnchangedValue | If an attribute is added to the session, that attribute is already
        present in the session under the same name and the attribute implements
         | 
| sessionActivityCheck | If this is  If  | 
| sessionLastAccessAtStart | If this is  If  | 
Standard Implementation
Tomcat provides two standard implementations of Manager for use — the default one stores active sessions, while the optional one stores active sessions that have been swapped out (in addition to saving sessions across a restart of Tomcat) in a storage location that is selected via the use of an appropriate Store nested element.
Standard Manager Implementation
The standard implementation of Manager is org.apache.catalina.session.StandardManager. It supports the following additional attributes (in addition to the common attributes listed above):
| Attribute | Description | 
|---|---|
| pathname | Absolute or relative (to the work directory for this Context)
        pathname of the file in which session state will be preserved
        across application restarts, if possible.  The default is
        null. | 
| persistAuthentication | Should authentication information be included when session state is
        preserved across application restarts? If  Please note that the session's  | 
| processExpiresFrequency | Frequency of the session expiration, and related manager operations. Manager operations will be done once for the specified amount of backgroundProcess calls (i.e., the lower the amount, the more often the checks will occur). The minimum value is 1, and the default value is 6. | 
| secureRandomClass | Name of the Java class that extends
         | 
| secureRandomProvider | Name of the provider to use to create the
         | 
| secureRandomAlgorithm | Name of the algorithm to use to create the
         | 
| sessionAttributeNameFilter | A regular expression used to filter which session attributes will be
        serialized for clustering/replication, or storage to any persistent store.
        An attribute will only be serialized if its name matches
        this pattern. If the pattern is zero length or  | 
| sessionAttributeValueClassNameFilter | A regular expression used to filter which session attributes will be
        serialized for clustering/replication, or storage to any persistent store.
        An attribute will only be serialized if the implementation
        class name of the value matches this pattern. If the pattern is zero
        length or  | 
| warnOnSessionAttributeFilterFailure | If sessionAttributeNameFilter or
        sessionAttributeValueClassNameFilter blocks an
        attribute, should this be logged at  | 
Persistent Manager Implementation
NOTE: You must set either the
    org.apache.catalina.session.StandardSession.ACTIVITY_CHECK or
    org.apache.catalina.STRICT_SERVLET_COMPLIANCE
    system properties to true for
    the persistent manager to work correctly.
The persistent implementation of Manager is
    org.apache.catalina.session.PersistentManager.  In
    addition to the usual operations of creating and deleting sessions, a
    PersistentManager has the capability to swap active (but
    idle) sessions out to a persistent storage mechanism, as well as to save
    all sessions across a normal restart of Tomcat.  The actual persistent
    storage mechanism used is selected by your choice of a
    Store element nested inside the Manager
    element - this is required for use of PersistentManager.
This implementation of Manager supports the following attributes in addition to the Common Attributes described earlier.
| Attribute | Description | 
|---|---|
| className | It has the same meaning as described in the
        Common Attributes above.
        You must specify
         | 
| maxIdleBackup | The time interval (in seconds) since the last access to a session
        before it is eligible for being persisted to the session store, or
         | 
| maxIdleSwap | The maximum time a session may be idle before it is eligible to be
        swapped to disk due to inactivity. Setting this to  | 
| minIdleSwap | The minimum time in seconds a session must be idle before it is
        eligible to be swapped to disk to keep the active session count below
        maxActiveSessions. Setting to  | 
| persistAuthentication | Should authentication information be included when sessions are
        swapped out to persistent storage? If  Please note that the session's  | 
| processExpiresFrequency | It is the same as described above for the
         | 
| saveOnRestart | Should all sessions be persisted and reloaded when Tomcat is shut
        down and restarted (or when this application is reloaded)?  By default,
        this attribute is set to  | 
| secureRandomClass | It is the same as described above for the
         | 
| secureRandomProvider | It is the same as described above for the
         | 
| secureRandomAlgorithm | It is the same as described above for the
         | 
| sessionAttributeNameFilter | A regular expression used to filter which session attributes will be
        serialized for clustering/replication, or storage to any persistent store.
        An attribute will only be serialized if its name matches
        this pattern. If the pattern is zero length or  | 
| sessionAttributeValueClassNameFilter | A regular expression used to filter which session attributes will be
        serialized for clustering/replication, or storage to any persistent store.
        An attribute will only be serialized if the implementation
        class name of the value matches this pattern. If the pattern is zero
        length or  | 
| warnOnSessionAttributeFilterFailure | If sessionAttributeNameFilter or
        sessionAttributeValueClassNameFilter blocks an
        attribute, should this be logged at  | 
In order to successfully use a PersistentManager, you must nest inside it a <Store> element, as described below.
Nested Components
All Manager Implementations
All Manager implementations allow nesting of a <SessionIdGenerator> element. It defines the behavior of session id generation. All implementations of the SessionIdGenerator allow the following attributes:
| Attribute | Description | 
|---|---|
| sessionIdLength | The length of the session ID may be changed with the sessionIdLength attribute. | 
Persistent Manager Implementation
If you are using the Persistent Manager Implementation
  as described above, you MUST nest a
  <Store> element inside, which defines the
  characteristics of the persistent data storage.  Two implementations
  of the <Store> element are currently available,
  with different characteristics, as described below.
File Based Store
The File Based Store implementation saves swapped out sessions in individual files (named based on the session identifier) in a configurable directory. Therefore, you are likely to encounter scalability problems as the number of active sessions increases, and this should primarily be considered a means to easily experiment.
To configure this, add a <Store> nested inside
  your <Manager> element with the following attributes:
  
| Attribute | Description | 
|---|---|
| className | Java class name of the implementation to use.  This class must
      implement the  | 
| directory | Absolute or relative (to the temporary work directory for this web application) pathname of the directory into which individual session files are written. If not specified, the temporary work directory assigned by the container is utilized. | 
Data source Based Store
The Data source Based Store implementation saves swapped out sessions in individual rows of a preconfigured table in a database that is accessed via a data sourcer. With large numbers of swapped out sessions, this implementation will exhibit improved performance over the File Based Store described above.
To configure this, add a <Store> nested inside
  your <Manager> element with the following attributes:
  
| Attribute | Description | 
|---|---|
| className | Java class name of the implementation to use.  This class must
      implement the  | 
| dataSourceName | Name of the JNDI resource for a JDBC DataSource-factory. Since this code uses prepared statements, you might want to configure pooled prepared statements as shown in the JNDI resources How-To. | 
| localDataSource | This allows the Store to use a DataSource defined for the Context
      rather than a global DataSource. If not specified, the default is
       | 
| sessionAppCol | Name of the database column, contained in the specified session table,
      that contains the Engine, Host, and Web Application Context name in the
      format  | 
| sessionDataCol | Name of the database column, contained in the specified session table,
      that contains the serialized form of all session attributes for a swapped
      out session. The column type must accept a binary object (typically called
      a BLOB). If not specified the default value of  | 
| sessionIdCol | Name of the database column, contained in the specified session table,
      that contains the session identifier of the swapped out session. The
      column type must accept character string data of at least as many
      characters as are contained in session identifiers created by Tomcat
      (typically 32). If not specified the default value of  | 
| sessionLastAccessedCol | Name of the database column, contained in the specified session table,
      that contains the  | 
| sessionMaxInactiveCol | Name of the database column, contained in the specified session table,
      that contains the  | 
| sessionTable | Name of the database table to be used for storing swapped out sessions.
      This table must contain (at least) the database columns that are
      configured by the other attributes of this element. If not specified the
      default value of  | 
| sessionValidCol | Name of the database column, contained in the specified session table,
      that contains a flag indicating whether this swapped out session is still
      valid or not. The column type must accept a single character. If not
      specified the default value of  | 
Before attempting to use the data source Store for the first time, you must create the table that will be used to store swapped out sessions. Detailed SQL commands vary depending on the database you are using, but a script like this will generally be required:
create table tomcat_sessions (
  session_id     varchar(100) not null primary key,
  valid_session  char(1) not null,
  max_inactive   int not null,
  last_access    bigint not null,
  app_name       varchar(255),
  session_data   mediumblob,
  KEY kapp_name(app_name)
);Note: The SQL command above does not use the default names for either the table or the columns so the data source Store would need to be configured to reflect this.
Special Features
Persistence Across Restarts
Whenever Apache Tomcat is shut down normally and restarted, or when an
    application reload is triggered, the standard Manager implementation
    will attempt to serialize all currently active sessions to a disk
    file located via the pathname attribute.  All such saved
    sessions will then be deserialized and activated (assuming they have
    not expired in the mean time) when the application reload is completed.
In order to successfully restore the state of session attributes,
    all such attributes MUST implement the java.io.Serializable
    interface.  You MAY cause the Manager to enforce this restriction by
    including the <distributable> element in your web
    application deployment descriptor (/WEB-INF/web.xml).
Note that, if persistAuthentication is also set to
    true, the Principal class present in the session
    MUST also implement the java.io.Serializable interface in order
    to make authentication persistence work properly. The actual type of that
    Principal class is determined by the 
    Realm implementation used with the application. Tomcat's standard
    Principal class instantiated by most of the Realms (except
    JAASRealm) implements java.io.Serializable.
The persistence across restarts provided by the StandardManager is a simpler implementation than that provided by the PersistentManager. If robust, production quality persistence across restarts is required then the PersistentManager should be used with an appropriate configuration.
Enable Session Persistence
As documented above, every web application by default has
    standard manager implementation configured, which can perform session
    persistence across restarts. To enable this persistence feature, create
    a Context configuration file for your web
    application and add the following element there (in this example,
    it will save sessions to files named SESSIONS.ser):
<Manager pathname="SESSIONS.ser" />