WAS v8.5 > Administer applications and their environment > Administer the Liberty profile > Administer the Liberty profile manually

Configure session persistence for the Liberty profile


Overview

When session data must be maintained across a server restart or an unexpected server failure, we can configure the Liberty profile to persist the session data to a database. This configuration allows multiple servers to share the same session data, and session data can be recovered in the event of a failover.


Persist session data to a database

  1. Define a shared session management configuration that we can reuse among all of your servers. You must at least:

    1. Enable the sessionDatabase-1.0 feature.

    2. Define a data source:

    3. Reference the data source from the session database configuration.

    4. Reference the persistent storage location from the session management configuration.

    For example, we can create a file named...

      ${shared.config.dir}/httpSessionPersistence.xml

    ...containing... 

    <server description="Demonstrates HTTP Session Persistence Configuration"> 
    < featureManager>
        <feature>sessionDatabase-1.0</feature>         <feature>servlet-3.0</feature>     </featureManager> 
    < httpEndpoint id="defaultHttpEndpoint" 
                  host="*" httpPort="${httpPort}"> 
        < tcpOptions soReuseAddr="true"/> 
    </httpEndpoint> 
    < fileset id="DerbyFiles" 
             includes="*.jar" 
             dir="${shared.resource.dir}/derby/client"/> 
    < library id="DerbyLib"
             filesetRef="DerbyFiles"/> 
    <jdbcDriver 
                libraryRef="DerbyLib"/> 
    <dataSource  jdbcDriverRef="DerbyDriver" 
                 jndiName="jdbc/sessions"> 
        < properties.derby.client 
            user="user1" 
            password="password1" 
            databaseName="${shared.resource.dir}/databases/SessionDB" 
            createDatabase="create"/> 
    </dataSource> 
    < httpSessionDatabase  dataSourceRef="SessionDS"/>     < httpSession storageRef="SessionDB" cloneId="${cloneId}"/> 
    < applicationtest" type="ear" location="${shared.app.dir}/test.ear"/>    

</server>

    When multiple servers are configured to persist session data to the same database, those servers must share the same session management configuration. Any other configuration is not supported. For example, it is not possible for one server to use a multi-row schema while another server uses a single-row schema.

    Best Practice: If session affinity is important to the application, explicitly define a unique clone ID for each server. In that way, we do not have to depend on the default clone ID generated by the server, and we can be certain the value of the clone ID never changes.

  2. Include the shared session management configuration in each of your servers. For example, create two server.xml files for server instances named s1 and s2, as follows:

    • ${wlp.user.dir}/servers/s1/server.xml
    • ${wlp.user.dir}/servers/s2/server.xml 

    <server description="Example Server">     < include location="${shared.config.dir}/httpSessionPersistence.xml"/> </server>

  3. Specify unique variables in the bootstrap.properties file of each server.

  4. You might have to create a table for session persistence before starting the servers.

    1. Optional: Use the httpSessionDatabase element to change the default row size, table name, or table space name.

    2. No additional action is required if your server is installed on one of the distributed operating systems. The server automatically creates the table.

    3. If wer server is using DB2 for session persistence, we can increase the page size to optimize performance for writing large amounts of data to the database.

  5. Optional: Integrate HTTP sessions and security in the Liberty profile.

    By default, after a session is created and accessed within a protected resource with security enabled, only the originating owner of that session can access it. Session security (security integration) is enabled by default.

  6. Optional: Install and configure the web server plug-in to route requests to each of the servers you configured.

    The session affinity is only maintained if your plug-in configuration specifies clone IDs that match the clone IDs defined in the server configuration.


Parent topic: Administer the Liberty profile manually


Related concepts:

The Liberty profile


Related

Specify Liberty profile bootstrap properties
Configure database connectivity in the Liberty profile
Switch to a multi-row schema
Create a table for session persistence
Create a z/OS DB2 table for session persistence
Configure table space and page sizes for DB2 session databases
Develop session management in servlets
Install and uninstall the Web Server Plug-ins on distributed operating systems


Reference:
Liberty profile: Directory locations and properties
Liberty profile: Configuration elements in server.xml
Session security support
HTTP sessions: Resources for learning


Related information:
plugin-cfg.xml file