This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
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)?
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.
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
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.