Session Migration

[Mark Garland]

Hi all,

Just something I wondered about using sessions in a distributed environment...

Lets say we have 4 servers behind a load balancer.
My first request is load balanced onto Server1, and a session is created there for me.
My second request is load balanced onto Server4, and my session is migrated across.

My question is how does Server4 know to look on Server1?
Does is just send out a broadcast message? - isn't this inefficient for large server farms?
Does the load balancer keep track, and so match the session id to the server name (so it tells 4 to ask 1 for the session)?

Thanks in advance,

MG

[Rahul Bhattacharjee]

I think there is nothing in the specification related to this.Vendors are free to implement this feature the way they want.

SRV 7.7.2 of servlet specification says about this.
[ May 24, 2007: Message edited by: Rahul Bhattacharjee ]

[Ben Souther]

There are different ways to load balance.

One route is to use sticky session at the load balancer level.
In this case the router/load balancer insures that a user is always sent to the same node in your cluster. How it works is product specific.

Another approach is to use session replication at the servlet container level.
In this case, each time a session is changed in any node, the change is broadcasted to all the other nodes in the cluster. This method is a little less efficient than the first because all the nodes have to maintain the complete session information for every client using the app but it gives you the advantage of being able to start and stop any node in the cluster without having to worry about interrupting service to any of your clients.

Some larger apps use a combination of the two so they can enjoy the benefits of both.

[Stan James]

With WebSphere we used a third option: saving the session to the database. WS provides several levers to control when and how much is written. With sticky sessions to make reading the database as rare as possible we are still able to stop and start servers in the cluster one at a time.

[Ben Souther]

Originally posted by Stan James:
With WebSphere we used a third option: saving the session to the database. WS provides several levers to control when and how much is written. With sticky sessions to make reading the database as rare as possible we are still able to stop and start servers in the cluster one at a time.

This is also a trade offs as it forces a database hit for any request that uses session variables.
Tomcat's session manager can be configured to do this as well.