Is there a possible "race condition" when using Asp.Net MVC TempData across a redirect?

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

Wimble

Answer 1

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.

Aroid

You are correct. If two browser windows share the same session, then they share the same TempData. You should be careful what you put into TempData for just this reason; flash status messages are okay (showing up in the wrong browser is a little odd but not harmful). – Torr

In the 7-step scenario in the question, it makes no difference whether the browser serializes all requests to the server. In fact, the scenario is serialized as POST-returning-redirect, AJAX-GET, GET-redirection-location. This means the AJAX-GET will receive the TempData. – Extrauterine

Also, doesn't IIS serialize all requests from the same session as soon as you use Session State anyway? This was certainly true back in the olden days. This would further emphasize the fact that request serialization makes no difference. – Extrauterine

The only kind of request serialization that would fix this in a redirect-GET scenario would be if the browser forces all redirect requests to execute immediately after the response that caused them. I think the main point here is @Brad's - don't put anything more important than flash messages in TempData. – Schnabel

Answer 2

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

Schizoid

So, it boils down to whether your site design will support TempData or not. This sounds like variation of all the quirks that always come with using session state. Like; cookies can be disabled; cookies can be deleted during a visit to the site, etc. – Extrauterine

Answer 3

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

Bouillabaisse

I updated my question to spell out the scenario I'm asking about. Now, I Understand my scenario is very rare, but it's still enough to make me hesitate in using TempData over just storing data in the session and removing it manually after a request. – Wimble

Doesn't the "Session object" have this problem? If you Session["Temp"] = null in all actions (which TempData effectively does, right?), then an action redirecting to another action would falsely assume Session["Temp"] is available in that other action. – Extrauterine

Answer 4

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.

Larder