MVC 3 tempdata container disadvantages

Question

Although the question title appears a bit subjective I am sure there is not a lot to discuss. I am currently working on a MVC project where I am using TemData container in some areas. When I read the documentation in MSDN, it appears that using TempData creates a session and that once read the data we store in tempdata is gone. I am OK with this concept, however the thing that kept bugging me this morning is that how does it behave when you host your application in a Web Farm environment.

What if a GET request is passed to SERVER 1, which creates a TempData and the subsequent GET/POST request is sent to SERVER 2.

I might be completely wrong with this assumption but I just need a clarification on this thinggy.

Any input will be deeply appreciated...

Cheers!

Answer 1

After doing some research, the scenario that I've posted in my question is inevitable if you use Session variables in your applications. The best thing we could do is to reduce the amount of data that we could store in a session, besides this if we still need to use sessions in a webfarm/multi server environment, there are some configuration changes that one can make. Here is a very useful article on how session storage can be managed.

ASP.NET Session how to FAQs

Answer 2

Yes, by default ASP.NET MVC store TempData in session. If session is inproc (default) and you are in web farm then you may not get the correct session data for the next request. If you are in web form then use other session storage method like state server or sql server.