How to setup and configure distributed sessions in WebSphere

Home > Search > How-to

A session is created when a web browser creates a connection to a WebSphere application, and the session is ended when the connection to the application is terminated, such as when the web browser is closed. Distrubuted sessions is the idea of distributing sessions across two or more application servers or applications in a cluster.

There are two session management levels. You can set the session management settings at the application server level, or at the application level. The settings at the application level will take precedence over the settings at the application server level.


  1. In the left panel of the WebSphere web console, expand Application > Application Types, and select Websphere enterprise applications.
  2. Select an application.
  3. Select Session management.
  4. Select Distributed environment settings.

Application server:

  1. In the left panel of the WebSphere web console, expand Server > Server Types, and select Websphere applications servers.
  2. Select an application server.
  3. Select Session management.
  4. Select Distributed environment settings.

By default, distributed environment settings is set to none.

  • None - Session data will be discarded when an application or application server is stopped or shut down. For example, if there are 2 JVMs in a cluster, and the first JVM goes down, all of the session with the first JVM will be discarded. This is usually not preferred when there are 2 or more JVMs in a cluster.
  • Database - Session data will be stored in a database.
  • Memory-to-memory replication - Session data is stored in a data source in memory. For example, if there are 2 JVMs in a cluster, and the first JVM goes down, the sessions with the first JVM will be stored in memory on the second JVM, so that sessions are not lost when the first JVM goes down. This has the added benefit of not having to setup and configure a database to store persistent sessions.


On the right side of the page, select Tuning level to tune how distributed sessions are handled. By default, the tuning level will be set to Custom settings.


Memory to Memory Replication

By default, Memory-to-memory replication displays "No replication domains have been defined", and the Memory-to-memory replication option cannot be selected. To use Memory-to-memory replication, you must first setup a replication domain. Select Memory-to-memory replication and then select New. Give the replication domain a name, select the request timeout, select the number of replicas, and then select OK and Save.

  • Single replica - This option is used to replicate the session from one application server or application to another application server or application.
  • Entire domain - This option is used to replicate the session to every application server that is configured as a consumer of the replication domain.


After creating a replcation domain, select the newly created replication domain, and then select a replication mode.

  • Both client and server - Every JVMs in the cluster will have copies of the other JVMs sessions.
  • Client only - The client will broadcast out it's own sessions to other servers, but will not store backup copies of other application server sessions.
  • Server only - The server will store a backup copy of other application server sessions, but does not broadcast out it's own sessions to other servers.


Session affinity

By default, a WebSphere application server uses session affinity. Session affinity allows WebSphere to assoicate requests from a certain browser to a certain JVM. For example, let's say you have two JVMs in a cluster. When a browser requests an application from the cluster, either JVM1 or JVM2 will send the browser the application. If JVM1 is the application server to send the browser the application, subsequent requests from the browser will route to JVM1, and will not invole JVM2. Likewise, if JVM2 were to send the application to the browser, then JVM2 would continue to answer the browsers requests, until the session is destroyed.

Session affinity improves performance, by allowing sessions to be accessed from cache in the application server, instead of having requests bounce between different application servers in a cluster.

Session affinity can be verified by checking the application server SystemOut.log file. When session affinity has been estabished with JVM1, only JVM1 SystemOut.log file should contain events from the browser. The same is true for JVM2.

~]# $was_home/profiles/<profile name>/servers/JVM1/logs/SystemOut.log
~]# $was_home/profiles/<profile name>/servers/JVM2/logs/SystemOut.log


Add a Comment

We will never share your name or email with anyone. Enter your email if you would like to be notified when we respond to your comment.

Please enter in the box below so that we can be sure you are a human.