Sticky session

what  I understands is, sticky session is a session which is  located in the central location of the server so that load balancer can be used for the particular user session in switching between the servers. My question is whether sticky session is same as the cookies.. ? what happens if the server goes down ?  did the sticky session stays...

People who have practical knowledge on this  please reply...

Thank you
Who is Participating?
dgrafxConnect With a Mentor Commented:
For web applications, clustering is a load-balancing technique in which multiple application servers are set up to behave as one big server. Generally this requires replicating HttpSession data across the servers, to ensure that a user's web interactions will continue without interruption regardless of which server handles the next request. Session replication achieves very high reliability, but it incurs an extra performance cost (due to the serializing and deserializing of session data and the extra network traffic required).
In contrast, Sticky Sessions (also called session persistence or sticky persistence) is a load balancing technique in which each session is assigned to a particular server for the duration of the session. This approach doesn't require copying HTTPSession data between servers, so it's very scalable. But if a server goes down, all of its sessions are lost.
In general, the sticky sessions approach is the way to go when possible (that is, when performance is more important than session survival). It represents a much more efficient use of resources ... you are scaling out not up, which is always cheaper. It also means that you don't have to be as careful about what goes into the HTTPSession.

Here is a whole bunch of info:
dpearsonConnect With a Mentor Commented:
Just to augment what dgrafx said which is all correct:

My question is whether sticky session is same as the cookies.. ?

No - cookies are stored in the user's browser.  A session is something that exists on the server.

Also beyond having either session replication or sticky sessions, another option is a hybrid approach.  In that model, the session is always backed by data stored in a database.  If the request is sent to a server, it first checks to see if it has the session in memory and if not loads it from the database.

With this model, if your load balancer supports sticky sessions then you get the performance benefits of sticky sessions (the same server gets all requests and has the session in memory).  However, if the server crashes and the requests need to go to a different server, it will load the session data from the database and proceed.  So then you get failover support as well.  I mention this because it's the approach we take to sessions - seems to give the benefits of both approaches without the weaknesses.

giltjrConnect With a Mentor Commented:
Although a cookie and a session are two different things, application servers use cookies to know which session object is yours.  If you have a J2EE server they typically use a cookie named JSESSIONID for tracking your session id.

Some load balancer use cookies to track which server your session is currently associated with.

So cookies and sessions are different, but cookies are used to identify your session.
All Courses

From novice to tech pro — start learning today.