Bootstrap FreeKB - IBM WebSphere - Storing sessions in a database or memory
IBM WebSphere - Storing sessions in a database or memory

Updated:   |  IBM WebSphere articles

If you are not familiar with how sessions are configured in WebSphere, check out our getting started page.

By default, sessions are stored in the application server the client is sending requests to.


If the application server becomes unavailable and the client is routed to a different application server, the clients will need to establish a new session. Distrubuted sessions allows you to store session in a database or in memory, so that way if the client needs to be routed from application server "a" to application server "b", the client will not need to create a new session, and instead, application server "b" will be able to get the session from the database or memory.


Additionally, let's say you've configured your application servers with a maximum in-memory session count of 1000 sessions and to allow overflow. Once the maximum in-memory session count has been reached then new sessions would be stored in memory on the application server and the oldest, unused sessions would be stored in the database or replicated to a different application server.


Assuming you have not enabled override session management at the application level, distributed sessions are configured at Server > Server Types > Websphere applications servers > your application server > Session management > Distributed environment settings.


By default, distributed environment settings is set to None, meaning session data will be discarded if the application server is stopped or becomes unavailable.



To store sessions in a database, you would first create a DB2 JDBC data source. The data source must be DB2. In other words, the data source cannot be some other database provider, such as MySQL, Microsoft SQL Server, or Oracle. Then, you can configure sessions to be stored in the DB2 data source. If possible, having a dedicated database for the sessions is ideal, so that performance isn't impacted by read/write requests to the database by other systems.


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 to another application server.
  • 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 application server in the cluster will have copies of the other application servers sessions.
  • Client only - The client will broadcast out it's own sessions to other application 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.


Tuning level

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.

Did you find this article helpful?

If so, consider buying me a coffee over at Buy Me A Coffee


Add a Comment

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