Chapter 18. High-Availability Web Sessions
- configure the server to use the session manager set on your web application (JBoss Application Server by default ignores the web application session manager and switches to JBossCacheManager automatically);
- configure your web applications to use DataSourcePersistentManager as their session manager (the manager handles the storing of web sessions to the defined database table);
- create the web session table in the target database and deploy the datasource, which will provide the connection between the session manager and the database table.
Configuring JBoss Enterprise Application Server
- Open the
JBOSS_HOME/server/PROFILE/deployers/jbossweb.deployer/META-INF/war-deployers-jboss-beans.xmlfile for editing.
- Set the overrideDistributableManager property of the
<bean name="WarDeployer" class="org.jboss.web.tomcat.service.deployers.TomcatDeployer"> . . . <!-- "False" disables overriding the session manager for distributable webapps --> <property name="overrideDistributableManager">false</property> </bean>
Configuring Web Application
- In the application's
WEB-INFdirectory, create the
context.xmlfile, which will define what session manager is to be used as well as the manager's attributes.
ImportantNote that it is not recommended to add the manager definition to the
jboss-web.xmlfile, although it is the standard web application deployment descriptor. The goal of using the
context.xmlfile instead is to avoid any unnecessary changes to the existing JBoss Application Server code.
- In the
context.xmlfile, add the Manager element and its attributes:
- fully-qualified class name of the session manager implementation
- datasource that allows the session manager to communicate with the database that stores the web sessions
<Context cookies="true" crossContext="true"> <Manager className="org.jboss.web.tomcat.service.session.persistent.DataSourcePersistentManager" dataSourceJndiName="java:HttpSessionDS"/> :</Context>
NoteThe className and dataSourceJndiName are compulsory attributes. You can also define further Context and Manager attributes (refer to Section 18.1, “DataSourcePersistentManager Configuration Attributes”.
Configuring Database and Datasource
- Create the web session ( httpsessions ) database table:You can change the name of the table and of the columns; however, make sure to configure the DataSourcePersistentManager attributes appropriately.Individual columns must be able to store values of particular datatypes:
The following command creates the table with default settings in the most common databases (MySQL, IBM DB2, Oracle Database):
- creationtime and lastaccess : java long values
- maxinactive and version : java int value
- metadata : serialized java objects (currently not used)
- attributes : serialized java objects (stores the session attributes map; should be large enough to store your largest sessions)
- primary key : synthetic primary key (optional, make sure there is a UNIQUE INDEX on app + id).
CREATE TABLE httpsessions (app VARCHAR(255) NOT NULL, id VARCHAR(255) NOT NULL, fullId VARCHAR(255) NOT NULL, creationtime BIGINT NOT NULL, maxinactive BIGINT NOT NULL, version INT NOT NULL, lastaccess BIGINT NOT NULL, isnew CHAR(1) NOT NULL, valid CHAR(1) NOT NULL, metadata VARBINARY NULL, attributes LONGVARBINARY NOT NULL, CONSTRAINT app_id PRIMARY KEY (app, id))
- Deploy an appropriate datasource to allow the DataSourcePersistentManager to communicate with the database (refer to the chapter on Datasource Configuration in the Administration and Configuration Guide. Make sure the datasource is set up as local-tx-datasource (xa-datasources are not supported).
- Add the dataSourceJndiName with the jndi-name of the created datasource to DataSourcePersistentManager element in the
18.1. DataSourcePersistentManager Configuration Attributes
- fully-qualified class name of the org.apache.catalina.Manager implementation (that is,
- JNDI name of the data source, which defines the database connection to the httpsessions
Properties Defining the Database Connection Properties
- value of the username parameter to pass to the
null, the getConnection with no arguments is called)
- password to pass to DataSource.getConnection
- name of the database session table in which sessions are stored (by default
- name of the column with the web application name associated with the session (by default
- name of the column with the core, immutable part of a session ID (by default
id; this and the sessionAppCol columns form the unique index for the table)
- name of the column with the full session ID (including any mutable element added to the core session ID, for example a jvmRoute; by default
- name of the column with the time when the session was created (of the long datatype, by default
- name of the column with the maximum number of milliseconds the session can remain unaccessed before expiring (by default
- name of the column which stores the session's "version" (session version is incremented each time the session is persisted; by default
- name of the column with the timestamp of the last session access (take the long data type value; by default
- Name of the column with the flag indicating whether the session is new (session is considered new if it was not yet joined by the client; by default
- name of the column with the flag indicating whether the session is valid (by default
- name of the column which can store serialized metadata about the session (currently unused; by default
- name of the column with the serialized session attribute map (by default
Properties Defining the Manager's Behavior
- minimum period of time in seconds that must lapse from the last cleaning of old "abandoned" sessions from the database before the next cleaning (by default 14400 seconds, that is, 4 hours)A session is abandoned if the only server that was handling the session requests was shut down before the session expired, no further requests for the session were received so that the session did not fail over to another server. Such session do not expire on the normal session expiration checks. Therefore a special process runs periodically to clean the session from the database.
- activity executed during a request that makes the session database persistent (the activity with the replication-trigger property SET)
- maximum interval between requests, in seconds, after which the session's timestamp is persisted regardless of whether the request caused the session to become dirty in any other way
- flag determining whether the container assumes a JK-based software load balancer is used for load balancing (if set to
true, the container examines the session ID associated with every request and replace the jvmRoute portion of the session ID if it detects a failover)
- maximum number of active sessions
- flag for enabling/disabling session passivation (session is removed from memory but remains always in the persistent store)
- minimum time, in seconds, a session must be inactive before passivated
- maximum time, in seconds, a session can be inactive before passivated
- frequency at which the background process thread calls the session manager to perform background processes (for example, expire or passivate sessions; (by default, every 10 seconds)This configuration is defined as value N with the background cleanup process called 1 in N callings to the session manager. Default is 1, that is, the cleanup process is performed every time the manager is called by the background process, that is cleanup is performed every 10 seconds. For example, if set to
6, the manager performs the cleanup once a minute (1/6, that is once in 60 seconds).
- fully qualified class name of the implementation of the ClusteredSessionNotificationPolicy interface that is used to govern whether servlet specification notifications is emitted to any registered HttpSessionListener, HttpSessionAttributeListener or HttpSessionBindingListener.