Session replication across JVMs in WebSphere

Question

We have an infrastructure set up where in the webservers are clustered and the application servers are not. The webservers route the request to the application servers based on round-robin policy.

In this scenario, the session data available in one application server is not available in the other application server. Is there anyway by which the session data from first application server can be made available in the second application ? The two application servers are physically separate boxes in different cells.

One approach could be to use the database - is there any other means of accomplishing this session replication ?

Answer 1

Here's an article on how to achieve this using WebSphere.

Answer 2

maybe you can look at 'terracota'. its an caching framework, which can cache sessions and runs on a seperate server

Answer 3

In WebSphere there are essentially two ways to replicate session data:

1. Persisting to a database
2. Memory-To-Memory transfers

Which one is appropriate for your needs is highly dependent on your application scenario:

How important is the persistence of your session data, when all your application servers go down? How many session objects do you have at any one time simultaneously?

In a DB you can store many sessions without much problems, the other option is always a question of how much memory is available.

I would go with the database, if you already got one set up, which all application servers use anyway.

Here is the link to the WebSphere Information Center with the necessary details.

Answer 4

don't forget oracle coherence.

Answer 5

One obvious solution is to enable clustering of your application servers. I assume from the way you worded your question you have rejected this option. Another option is to change the routing used by the web servers to use session affinity (requests for the same session go to the same app server).

Other that that, I'd second the answer by dertoni.

Answer 6

There are two options for clustering within WebSphere, session replication or database. If you have large session objects you are best off using database because it allows you to offload stale sessions to disk. If they are then represented then they can be extracted from the database, if you use session replication then those sessions need to stay in memory on not just your target server but also the other servers in the replication group. With large sessions this can lead to an out of memory condition.

With database session handling it is also very customisable and doesn't performance noticeably in the environments that I have used it.