Sticky Sessions and Session Replication: A method used with Application Load Balancing, to achieve server-affinity.
Sticky session WITHOUT session replication
A router or load balancer with sticky-session support can assign a single server to a particular user, based on their HTTP session or IP address. The assigned server is remembered by the router for a certain amount of time, ensuring that all future requests for the same session are sent to the same server.
When your website is served by only 1 web server, for each pair, a session object is created and remains in the memory of the web server. All the requests from the client go to this web server and update this session object. If some data needs to be stored in the session object over the period of interaction, it is stored in this session object and stays there as long as the session exists.
However, When you use loadbalancing it means you have several instances of tomcat and you need to divide loads. if your website is served by multiple web servers which sit behind a load balancer, the load balancer decides that which web server should serve the user requests. For example, if there are 3 webservers A, B and C behind the load balancer, it is possible that http://techdiary.in/index.jsp is served from server A, http://techdiary.in/login.jsp is served from server B and http://techdiary.in/accoutdetails.php are served from server C.
Now, if the requests are being served from (physically) 3 different servers, each server has created a session object for you and because these session objects sit on 3 independent boxes, there’s no direct way of one knowing what is there in the session object of the other. In order to synchronize between these server sessions, you may have to write/read the session data into a layer which is common to all – like a DB. Now writing and reading data to/from a db for this use-case may not be a good idea. Now, here comes the role of sticky-session. If the load balancer is instructed to use sticky sessions, all of your interactions will happen with the same physical server, even though other servers are present. Thus, your session object will be the same throughout your entire interaction with this website.
A big Disadvantage of session stickiness is when web server goes down or web service gets restarted then session will be killed and user will be disconnected from that web server. Best example is shopping cart where items are kept in the HttpSession and shutting down would require the user to re-purchase them (which would likely lead to a lost sale).
Session replication is a mechanism used to replicate the data stored in a session across different instances. However, the replicated instance must be part of the same cluster. When session replication is enabled in a cluster environment, the entire session data is copied on a replicated instance.
Session replication along with load balancing provides good failover capabilities for web applications.
Imagine the user using your web app, and you have 3 tomcat instances. This user sends several requests to your app, then the loadbalancer will send the first user request to one of the three tomcat instances, and all the other requests that are sent by this user during his session will be sent to the same tomcat instance. During these requests, if you shutdown or restart this tomcat instance (tomcat instance which is used) the loadbalancer sends the remaining requests to one other tomcat instance that is still running, as you use session replication, the instance tomcat which receives the remaining requests has a copy of the user session then the user keeps on his session : the user continue to browse your web app without being disconnected, the shutdown of the tomcat instance doesn’t impact the user navigation.
If you found any of the information on this page helpful in anyway then please consider sharing this content with your favorite social network or by leaving your thoughts in the comment section. Thanks!