异步Web请求，EntityFramework和DI，它是如何工作的？

Question

我搜索了很多关于这些主题的内容，但我仍然不确定它是否按预期工作。为什么。

我的理解：

• 处理Web请求时，您正在使用其池中的一个IIS线程。在该请求中，如果您使用异步调用（例如，从数据库查询某些数据），则释放该线程，以便IIS可以使用该相同的线程来处理另一个调用。非常好。可能。
• 稍后当数据库最终提供等待的数据时，代码将恢复。异步文档提到您现在可能在另一个线程中。或不。 DotNet的决定。如果它和以前在同一个帖子中，那没关系。
• 我使用依赖注入在PerRequest生命周期中注入和关闭上下文（使用Microsoft Unity）。关闭是我的主要关注点。它在我的同步世界中完美运行：dbcontext在我的Web请求结束时关闭。
• 已知EntityFramework的DbContext非线程安全

问题1：现在，如果恢复代码在另一个线程中，它是否来自同一个线程池，IIS必须处理所有请求，还是来自另一个端池？

问题2：如果代码在另一个线程中运行，那么WebRequest上下文呢？ DI会在异步代码真正结束之前正确跟踪延迟调用的结束而不调用Dispose（）吗？

问题3：如果我使用EntityFramework的异步方法，比如ToListAsync或FirstOrDefaultAsync，我会在任何地方读到＆＃34;它应该没问题＆＃34;。有人可以详细说明吗？ EF是否专门跟踪Web请求或初始线程？是否有某种捕获事件发生？我的dbcontext是否会与另一个重用我的初始线程的Web请求混在一起？

问题4：如果我使用EntityFramework的普通（sync）方法，但包含在Task中。什么会发生？它仍然是＃34;应该没问题＆＃34;？

对不起，这是很多问题，很长一段时间以来一直困扰着我。

Answer 1

好吧，我现在可以尝试回答我自己的问题了。

问题1 ： 来自Do asynchronous operations in ASP.NET MVC use a thread from ThreadPool on .NET 4

  

是 - 所有线程都来自线程池。您的MVC应用程序已经是多线程的，当请求进入新线程时，将从池中获取并用于为请求提供服务。该线程将被“锁定”（来自其他请求），直到请求完全得到服务并完成。如果池中没有可用的线程，则请求必须等到一个可用。   如果您有异步控制器，他们仍然从池中获取一个线程，但在处理请求时，他们可以放弃线程，同时等待某些事情发生（并且该线程可以被赋予另一个请求）以及当原始请求需要一个线程时再次它从池中获得一个。

问题2：如果代码在另一个线程中运行，那么WebRequest上下文呢？

来自ewk和http://vegetarianprogrammer.blogspot.fr/2012/12/understanding-synchronizationcontext-in.html 并https://msdn.microsoft.com/en-us/magazine/gg598924.aspx

SynchronisationContext将确保在恢复执行时在当前线程上正确设置Web请求（HttpContext.Current）。这是ASP.NET后台工作的一部分。

DI会在异步代码真正结束之前正确跟踪延迟呼叫的结束并且不调用Dispose（）吗？

由于Web请求可能在多个线程上流动，并且不以最初的线程结束，因此我看不出为什么EndRequest事件将在总流量完成之前触发的任何原因。因此，我认为没有理由为什么PerRequestLifeTimeManager或其他PerRequest策略会在需要之前通过调用一些Dispose（）来失败。

问题3à4：异步和EF。正如ewk所提到的，只要你不在同一时间在不同的线程中使用它，Entity Framework就是安全的。由于问题3和4都显示了不同的方式来命中DbContext，答案是：为了安全起见，无论运行任务的方式如何，都应该只有一个同时访问DbContext。正如ewk所提到的，使用相同的dbcontext明确地旋转2个任务是不安全的。