Session Persistence

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.

File

The session data is stored on a shared filesystem.

JDBC

The session data is stored in a database table.

Cookie-based

The session data is stored at the client end in a cookie.

In-memory replication

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.

We will examine each persistence mechanism in detail later in this chapter, with a separate section dedicated to in-memory replication. Usually, any kind of Java object can be bound to the session. However, if you want to use session persistence, certain restrictions are imposed. If you have configured the session persistence to use either file, JDBC, or in-memory replication, an object must implement the java.io.Serializable interface before it can be bound in the session. If you have configured session persistence to use cookies instead, only strings may be bound in the HTTP session.

2.6.1 Configuring Session Persistence

The following properties can be set in the session-descriptor element in the weblogic.xml configuration file.

CacheSize

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.

InvalidationIntervalSecs

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.

PersistentStoreType

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.

Table 2-4. Table definition for wl_servlet_sessions

Column name	Type
wl_id	A variable-width alphanumeric column holding up to 100 characters
wl_context_path	Same as wl_id
wl_is_new	A single character column
wl_create_time	A numeric column of length 20
wl_is_valid	A single character column
wl_session_values	A large binary column
wl_access_time	A numeric column of length 20
wl_max_inactive_interval	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:

• The user's browser must be configured to accept cookies.
• Only string-valued attributes may be stored in the session. WebLogic will throw an IllegalArgumentException if you attempt to assign any other type of object to a session attribute.
• Cookies are written in an HTTP response header, which must be written before any content. For this reason, you should not flush the HTTP response, or else cookie data cannot be written. Note that buffers are automatically flushed when they reach the default buffer size (12 KB), in which case the cookie data will not be updated. (You can change the default buffer size by calling the setBufferSize( ) method on the ServletResponse object.)
• You may use only basic, browser-based authentication.
• By default, the session data stored in a cookie is not encrypted in any way. If your session is holding sensitive information that must never be tampered with, you should consider the potential security risks of exposing this data to the client's browser.