Disadvantages of the container in MVC 3 tempdata

Question

Although the title of the question seems a bit subjective, I am sure there is nothing to discuss. I am currently working on an MVC project where I use the TemData container in some areas. When I read the documentation on MSDN, it seems that using TempData creates a session and that after reading the data stored in tempdata it disappears. I have everything in order with this concept, however, what continued to listen to me this morning is how it behaves when you host your application in a Web Farm environment.

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

I may be mistaken in this assumption, but I just need to clarify this thing.

Any input will be deeply appreciated ...

Hurrah!

Answer 1

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

ASP.NET segment as frequently asked questions

Answer 2

Yes, by default, ASP.NET MVC stores TempData in a session. If the inproc session (default) and you are in a web farm, you may not get the correct session data for the next request. If you are in a web form, use another session storage method, such as a state server or sql server.