Session persistence involves persisting the data stored in the HTTP session object. This typically is done to support failover across a cluster of servers. For instance, if the session state is duplicated between two running servers, and if one goes down, the other server can take over and no data is lost. WebLogic supports five different mechanisms for persisting session state information:
Memory (single-server, nonreplicated)
The session data is stored on a single server in memory.
The session data is stored on a shared filesystem.
The session data is stored in a database table.
The session data is stored at the client end in a cookie.
The session data is stored in memory on multiple servers.
By default, WebLogic stores session state information in memory in a nonreplicated manner. The other four persistence mechanisms are desirable when the web application is deployed in a WebLogic cluster. Session persistence allows WebLogic Server to support automatic session failover. Session failover ensures that a server failure remains transparent to the user another server will seamlessly pick up the backup of the session data. Because the session data is now persistent and accessible to multiple server instances, session information isn't lost when the server goes down. Clearly, session persistence will be more expensive than just storing the session data in memory on a single server. The session caching mechanism can help alleviate this cost.
2.6.1 Configuring Session Persistence
The following properties can be set in the session-descriptor element in the weblogic.xml configuration file.
This property determines the number of sessions that are cached in memory. The default value is 256. If your site holds a large number of sessions, but these sessions are not always active, you will want to cache the most-often used sessions. A Least-Recently Used (LRU) algorithm is used to swap sessions out to whichever persistence store is in use if the cache size is reached, and to swap them back in again when needed. Of course, the persistence mechanism has to be configured for this to work. Otherwise, the value is ignored and the number of sessions held in memory is limited only by the amount of memory available. The minimum value is 16 and the maximum is Integer.MAX_VALUE.
This parameter determines the period between the executions of the house-cleaning tasks. If a session is deleted or times out after session-timeout minutes, the house-cleaning task removes all data associated with the session, freeing up server resources. You typically will set this value to less than the value of the session-timeout element. The minimum value is 1, the maximum is 604800 (a week), and the default is 60.
This property sets the type of the persistence mechanism to be used. Its value can be one of the following values: memory, file, jdbc, cookie, or replicated. The default value for this setting is memory.
You can set the session timeout and session invalidation interval from the Administration Console. These settings can be configured from the Configuration/Descriptor tab for a selected web application.
2.6.2 Memory Persistence
By default, WebLogic stores all the session-state information for a server in memory. This implies that the number of concurrent sessions is limited by the amount of heap space available to the particular server instance. If you do not specify a sufficiently large heap size when you start WebLogic Server, you may run out of memory under severe load. It also means that if the server is stopped or fails for some reason, you lose all the session information.
Thus, by default, session data isn't persistent and cannot survive the lifetime of the server. For development environments, the default setting is sufficient. In a production environment where your deployment consists of multiple servers, you will require session failover when one of the servers fails. The other four possible values for the PersistentStoreType property provide automatic session failover. No further configuration is necessary for memory persistence.
2.6.3 File-Based Persistence
Setting the persistence type to file enables WebLogic to persist session-state information on the filesystem. In addition, you may specify the directory on the filesystem where the session information will be stored, using the PersistentStoreDir session parameter in the weblogic.xml descriptor file:
PersistentStoreType file PersistentStoreDir tmp_sessions
If you do not specify a directory, WebLogic Server will automatically create a temporary directory. Note that if you are using file-based session persistence in a cluster, you must ensure the attribute is set to a shared directory that is accessible to all the servers in the cluster. Typically, this directory will reside on high-performance disks with built-in support for failover.
2.6.4 JDBC Persistence
Setting the persistence type to jdbc enables WebLogic to store session data in a database table. If you choose to use the database for persisting session data, you must also specify the name of the connection pool that will provide JDBC connections to the database. The PersistentStorePool session parameter defined in the session-descriptor element in the weblogic.xml descriptor file lets you specify the name of the connection pool:
PersistentStoreType jdbc PersistentStorePool myJDBCPool JDBConnectionTimeoutSecs 60
The JDBConnectionTimeoutSecs property determines how long the persistence mechanism will wait to retrieve session data from the database. It defaults to 120 seconds. You must ensure the JDBC pool is accessible to all permitted users. Otherwise, the server will fail to save the session data.
An SQL table called wl_servlet_sessions must also be created. The database user associated with the connection pool must have read/write access to this table. Table 2-4 defines the structure of this database table, listing the name and type of each column.
A variable-width alphanumeric column holding up to 100 characters
Same as wl_id
A single character column
A numeric column of length 20
A single character column
A large binary column
A numeric column of length 20
An integer column
The primary key for this table is a compound key comprising two columns: wl_id and wl_context_path. Example 2-4 provides the SQL needed to create such a table on an Oracle database.
Example 2-4. SQL for creating the table to store session persistence information for JDBC-based session persistence
create table wl_servlet_sessions ( wl_id VARCHAR2(100) NOT NULL, wl_context_path VARCHAR2(100) NOT NULL, wl_is_new CHAR(1), wl_create_time NUMBER(20), wl_is_valid CHAR(1), wl_session_values LONG RAW, wl_access_time NUMBER(20), wl_max_inactive_interval INTEGER, PRIMARY KEY (wl_id, wl_context_path) );
The SQL script needed to create the table on other DBMS products will closely resemble the previous SQL statement. Note that although JDBC persistence provides the most robust way of persisting session data, its performance is also by far the poorest.
2.6.5 Cookie Persistence
Setting the persistence type to cookie enables WebLogic to store session data on the client browser itself. Unlike other persistence mechanisms, which store the session data on the WebLogic Server, this approach saves the session data on the client side, and the data then gets transported between the client and the server. In order to effectively use cookie-based persistence, you should persist only small amounts of session data because the cookie data needs to be transferred to and fro many times. Nevertheless, cookie-based persistence does have a significant advantage: because there is no server-side state, you don't need to configure any failover support for the cluster, and the servers can be stopped and started without losing session data.
You also can use the PersistentStoreCookieName property to specify the name of the cookie used for session persistence:
PersistentStoreType cookie PersistentStoreCookieName MYWLCOOKIE
The default name for the session persistence cookie is WLCOOKIE. There are limitations to using this form of persistence:
Managing the Web Server
Using JNDI and RMI
Using CMP and EJB QL
Packaging and Deployment
Performance, Monitoring, and Tuning
Logging and Internationalization