是否存在可能的“竞争条件”？ 在重定向中使用 Asp.Net MVC TempData 时？
当使用 TempData 时，我的理解是，它只会为一个请求保留您放入其中的任何内容。 因此，当使用 TempData 跨重定向保留数据时（为了使用 Post-Request-Get 模式），在发送重定向的响应和发送重定向的响应之间，来自用户的其他请求是否可能进入服务器？用户的浏览器请求重定向到的页面？ 在这种情况下，get 将不再有 TempData 可用，对吗？
现在，我知道发生类似的事情是非常罕见的，但考虑到用户可能在另一个选项卡中打开另一个页面，并且该页面上可能发生 ajax 或定时回调请求，它突然不会对我来说这一切都是不可能的。 人们普遍认为它太遥远而无需担心，还是我误解了什么？
编辑：更具体地说明我所询问的场景。
- 在选项卡 1 中，用户浏览到一个页面 使用帖子表单
- 在选项卡 2 中，用户浏览到网站上的另一个页面 计时器上的 ajax 回调
- 在选项卡 1 中，用户将表单发布到服务器
- 当服务器收到帖子时，它会在 TempData 中保存一些数据 并发回重定向响应
- 在选项卡 2 中，发生定时 ajax 回调，向服务器发送 GET 请求。 TempData 已从会话中删除
- 在选项卡 1 中，浏览器接收重定向并发出 GET 请求
- 服务器处理 GET 请求并查找 TempData，但它不再存在
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.
- In Tab 1 the user browses to a page
with a post form - In Tab 2 the user browsers to another page on the site that does
ajax callbacks on a timer - In Tab 1, the user posts the form to the server
- When the server receives the post, it saves some data in TempData
and sends back a redirect response - In tab 2, the timed ajax callback happens, sending a GET request to the server. The TempData is removed from the session
- In tab 1, the browser receives the redirect and issues a GET request
- The server processes the GET request and looks for the TempData, but it's not there anymore
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
好吧，浏览 ASP.NET MVC 代码会发现，虽然 TempData 存储在会话中，但在加载时会从会话中删除。 它被加载到控制器的 ExecuteCore() 方法中。
所以我认为这意味着是的，您完全可能会遇到竞争条件，其中来自不同浏览器选项卡的请求（您有一个很好的示例）可能会导致此问题。 但这取决于每个浏览器处理请求的模型。 浏览器可能会将所有请求序列化到同一台服务器，以便一次只执行一个。 但实际上，他们不会这样做，他们会将其上限限制为（我认为）对同一服务器的最大并发请求数。
鉴于 ASP.NET MVC 站点可以是对任何浏览器（毕竟是 Web :)）的服务请求，这是一个真实的场景，尽管可能很少见，正如您所说。
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.
使用 TempData 时完全有可能出现竞争条件。 然而，在正常使用情况下，你当然必须“不幸”才能体验到它。 为了遇到竞争条件，以下条件都必须为真：
请注意，第 2 项在很大程度上取决于您使用的浏览器。 根据您对 IE 的设置方式，仅仅因为您打开了多个窗口并不意味着它们共享浏览器 cookie，因此它们不一定共享会话（基于 cookie）。
然而，不存在竞争条件，即如果你遇到某物就会爆炸。 这可能就是 Haacked 所指的。 但是，您可能遇到竞争条件，因为您在一个请求中设置了一些 TempData，然后没有在您认为要去的下一个请求中取回它为拿到它，为实现它。 它只会是空的。
谢谢，
艾隆
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:
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 使用 Session 对象，据我所知，它不会遇到这个问题。 您遇到过这方面的具体问题吗？
TempData makes use of the Session object, which does not suffer this problem, AFAIK. Have you run into a specific problem with this?
我认为这永远不会发生，尽管一开始我也有同样的困惑。想想如果你在调试模式下运行你的 mvc web 应用程序，然后你在重定向操作中设置一个断点。然后你给 tempdata 一个值，然后你会在redirect viewResult和另一个视图中得到tempdate，你会发现在redirect操作完成之前其他请求永远不会被响应。那么什么意思呢？它说mvc应用程序以单线程模式运行，它可以处理一个一次单个请求。所以您提到的上述情况永远不会发生。
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.