When building an ASP.NET MVC application with a goal of high availability, is it a good practice to keep the session state on the SQL Server, if there is no state server available?
Share
Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
When building an ASP.NET MVC application with a goal of high availability, is it a good practice to keep the session state on the SQL Server, if there is no state server available?
The point here realy is that you have 2-3 webservers like you mentioned in the comment to Craigs answer.
One way is to use SQL-server sessionstate which has its own problems http://idunno.org/articles/277.aspx.
If you have this one SQL-Server I would be carefull, because the DB for sessionstate will put heavy load on it. Each request will write to the db.
We use 2 webservers and a Loadbalancer that has sticky sessions. If your first request ends up in server 1 then all your requests are handled by server 1. (Its a bit more sophisticated but you get the idea.)
This might not allways be the best solution, but at least on our site (its a shop where user typically stay 20-30minutes) it works well. We use only little SessionState and have most of the userspecific stuff stored by the ProfileSystem. But I guess the ProfileSystem will also fail if requests go to different servers.