[Okta Webinar] Learn how to a build a cloud-first strategyRegister Now

  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1077
  • Last Modified:

How to handle sessions in a web farm with no cookies??

I'm trying to figure the best way to handle sessions in an e-Commerce web farm environment. What my setup is that I have a website that connects to a remote ODBC server to grab data for the website. The shopping cart generates server side session files, no client cookies at all are being used. What is the best way to handle sessions in a web farm without using cookies at all? Is it possible to handle cookies with a database? In my server session files, I keep a lot of data on my users, so I can't image putting all this info into a database since there would be hundreds of records per user. The session table would also be hit tremendously so I'm weary about putting this load on the database server. How is this usually handled?

What I'm trying to do is have a farm of webservers with my website copied on all the boxes, then a load balancer on the front of the network would route to the least used server. This would be constantly happening, even in the middle of user's sessions, which is why I have to come up with something better than server side sessions residing on each webserver. Any ideas? I would greatly appreciate any help or feedback.
3 Solutions
Dan McFaddenSystems EngineerCommented:
I have a similar setup (but with client side cookies) but the session issue is the same.  These statements are only true if you use the .NET platform.

You can use InProc session state, if you are using the .NET platform.  If you use InProc session management, you will have to use a sticky source ip load balancing configuration, because you session state is managed by the web application you initially started talking to.  If you use a least conn balancing method with this config, your users will loss their state when they hit a different server in the farm.

Or, you could use an 'Out of Proc' session manager (see ASP.NET State Manager service) to store your user's session state.  You take a minor performance hit, but now you can use a least conn balancing routine on the load balancer.  Only problem is that the state management service is not clusterable so you will have a single point of failure being the session manager service.

If you have a budget for the project, you could look into to a third party session manager that builds in redundancy.  I am prepping to deploy software from, http://www.scaleoutsoftware.com/  to resolve this same issue.
Please see the following URL's as they describe exactly what you want to accomplish:


I'm not sure from your description why client-side cookies wouldn't work for you, so I'll explain how they work in a typical load-balanced situation:

Generally, there are two types of persistence provided by a load balancer.  The "more" complicated is cookie persistence.  However, it seems to me that this would work for you since it is done completely transparent to the server.  The load balancer simply injects a cookie into traffic going from the server back to the client.  When that client returns to the web site, the cookie is interpreted by the load balancer and the client is sent back to the same server.

The other approach that is generally used is IP persistence.  This approach works very well for lower-traffic sites, as it requires that the load balancer keeps records of client connections.  If there are too many of these records, they need to be erased or the load balancer may run out of resources.

Hope this helps.  Let me know if you'd like any clarification.

Featured Post

[Webinar] Cloud and Mobile-First Strategy

Maybe you’ve fully adopted the cloud since the beginning. Or maybe you started with on-prem resources but are pursuing a “cloud and mobile first” strategy. Getting to that end state has its challenges. Discover how to build out a 100% cloud and mobile IT strategy in this webinar.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now