Question

When using TempData, my understanding is that it will keep whatever you put in it around for only one request. So when using TempData to retain data across a redirect (in order to use the Post-Request-Get pattern), isn't it possible that some other request from the user could come into the server in between the response sending the redirect and the user's browser requesting the redirected-to page? In which case the get would no longer have the TempData available, correct?

Now, I understand that something like that happening would be very rare, but taking into consideration that the user might have another page open in another tab, and there might be either ajax or timed callback requests occuring on that page, it suddenly doesn't seem all that impossible to me. Is it just generally considered to be too remote to worry about, or am I misunderstanding something?

Edit: To be more specific about the scenario I was asking about.

  1. In Tab 1 the user browses to a page with a post form
  2. In Tab 2 the user browsers to another page on the site that does ajax callbacks on a timer
  3. In Tab 1, the user posts the form to the server
  4. When the server receives the post, it saves some data in TempData and sends back a redirect response
  5. In tab 2, the timed ajax callback happens, sending a GET request to the server. The TempData is removed from the session
  6. In tab 1, the browser receives the redirect and issues a GET request
  7. The server processes the GET request and looks for the TempData, but it's not there anymore
Was it helpful?

Solution

Well, browsing the ASP.NET MVC code shows that the while TempData is stored in the session, it is removed from the session when it is loaded. And it gets loaded in the Controller's ExecuteCore() method.

So I think that would mean that yes, you entirely could run into a race condition where a request from a different browser tab (you had a pretty good example) could cause this problem. But that would depend on each browser's model for handling requests. A browser might serialize all requests to the same server so that only one executes at a time. In reality, they won't do that, though, they'll cap it at the max which is (I think) 5 concurrent requests to the same server.

Given that an ASP.NET MVC site could be services requests to any browser (it's the web, afterall :) ) it is a real scenario, albeit probably a rare one, as you said.

OTHER TIPS

It is entirely possible to have a race condition when using TempData. However, you'd have to of course be "unlucky" to experience it under normal usage. In order to run into the race condition the following must all be true:

  1. You have to be using TempData to begin with.
  2. You have to have multiple browser windows/tabs/whatevers open and sharing the same browser session.
  3. A request from the second browser tab has to "sneak in" between the request and response of the first browser tab.

Note that item #2 depends a lot on which browser you're using. Depending on how you have IE set up, just because you have multiple windows opened does not mean that they share browser cookies, and thus they do not necessarily share sessions (which are based on cookies).

However, there is no race condition in the sense that something explodes if you run into it. That might be what Haacked is refering to. But you can hit a race condition in the sense that you set some TempData in one request and then didn't get it back in the next request where you thought you were going to get it. It'll just be empty.

Thanks, Eilon

TempData makes use of the Session object, which does not suffer this problem, AFAIK. Have you run into a specific problem with this?

I think it will be never happen,though at beginning I have the same confusion.Think about that if you run your mvc web application in debug mode,then you set a break point in a redirect action .And you give tempdata a value ,then you'll get the tempdate in redirect viewResult and the other view,you will found that the other request never be responsed until the redirect action completed .So what's mean?It said that the mvc application run in single thread mode,it can process a single request in one time.So the scenario above you mentioned can never happen.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top