I am using the TempData in order to preserve my model in when using a RedirectToAction. It works fine, but I have a nagging feeling that it might not be the right thing to do. I really try to avoid using Session data, and I've read that TempData uses the Session. Is it safe to use? Are there issues which might arise in using it in a load balanced environment?
Trivia Question: "Is It Safe?"-- name the movie.
Yes, TempData is backed by session storage, so if you are in a load balanced environment extra care must be taken when using it (sticky sessions, persistent session state, etc).
TempData has been the de-facto choice when using the PRG pattern, and is what it was designed for.
As to whether it's the right thing to do... it depends on your use case!
PS Marathon Man.
Well, I would argue that it depends. If you handle lot of traffic with load balancers and multiple front end server, then session objects is something to avoid because it could degrade performance and make hotizontal scaling difficult (on farm request doesn't come always to same web server).
TempData is short-lived, and if you don't put there lot of objects there and think twice about whole architecture, I think then it's safe. There's lot of sites that use it extensively and don't have problems with it (I worked on shared and dedicated hosted sites with up to avarage 50-70k visitors/day that use session, often with web and db on same server).
I would go, whenever possible, for a fully stateless approach. It's more scalable and is not affected by problems with individual servers. Typically, you can just use a cookie (properly secured against tampering) to identify the user and pull the data from the database every time.
Besides that, I also suggest you to evaluate whether you can use View instead of RedirectToAction. This:
TempData["model"] = model;
return RedirectToAction("SomeAction");
Can be replaced with:
return View("SomeAction", model);
Of course assuming "SomeAction" is a valid view that is accessible from the current controller (it's either a view in the same ctrl or one defined in Shared) and that it's not just an intermediate action that redirects to another one.
Session state can work in a clustered environment, providing that one of two things happens
- Your load balancer supports "sticky" sessions (i.e. all requests in a given session are routed to the same machine)
- You configure the session provider to use an out of process session provider, you can use either the ASP.NET State Service or the SQL Session State Provider
The question of whether you should use tempdata or not is a different question altogether. I would argue that there is usually a way around it. If you are trying to avoid a hit to the database to reload an object that one action has already loaded, look at using a cache instead.
I have limited the use of TempData to pass model object validation message between views and action. I haven't looked into the usage of Tempdata from security perspective but following SO thread discuss the same : HttpContext.Items with ASP.NET MVC. See the last few thread comments and related discussions.
来源：https://stackoverflow.com/questions/8243613/tempdata-is-it-safe