When there is only 1 server
serving all requests, a session object is created by webserver for each client
and it remains in memory of the web server. Same session is used for all
requests for that particular client.
However, if there are multiple servers are working behind the load
balancers, it becomes the responsibility of load balancer to decide which server
a particular request will be re-directed.
For example, if there are 4 webservers S1, S2, S3 and S4 behind the load balancer, it is possible that
http://javaterritory.blogspot.com/2016/03/method-overriding-in-java.html is served by server S1,
http://javaterritory.blogspot.com/2016/03/inner-class-in-java.html served from server S2,
http://javaterritory.blogspot.com/2016/04/difference-between-save-saveorupdate.html is served from server S3,
http://javaterritory.blogspot.com/2016/09/session-management.html served from server S4.
In this case, since there are 4 servers which are actually serving different requests from same client, 4 different sessions will be maintained by each server. This way of managing
sessions is termed as non-sticky session.
But this could lead to many potential problems as there are different sessions maintained
for same client. To overcome these problems, you may have to write code to
migrate session data to a common layer where each server can read. This is
exactly what done by what is known as sticky-session.
You can configure load balancer
to use sticky-session. With sticky
session configured, all the requests will be directed to same server and it
will manage the session throughout the interaction with a client.
I you are working with Apache
web server, following link gives steps to configure sticky session:
To
summarize, in case of sticky sessions, all requests for a client will go to the
same physical web server while in case of a non-sticky load-balancer may choose
any webserver to serve your requests, even if they are for same client.
0 comments:
Post a Comment