Session Migration
Mark Garland
Ranch Hand
Posts: 226
posted 10 years ago
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
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
28/06/06 - SCJP - 69%, 05/06/07 - SCWCD - 92%, 28/02/08 - IBM DB2 v9 Fundamentals (Exam 730) - 87%, 18/11/08 - IBM DB2 v9 DBA (Exam 731) - 89%, 26/02/11 - SCBCD - 88%
Rahul Bhattacharjee
Ranch Hand
Posts: 2308
posted 10 years ago
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.
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
(instanceof Sidekick)
Ranch Hand
Ranch Hand
Posts: 8791
posted 10 years ago
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.
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
posted 10 years ago
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.
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.
