c# - 异步 Web Request、EntityFramework 和 DI，是如何工作的？

Question

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

我的理解:

• 在处理网络请求时，您正在使用其池中的一个 IIS 线程。在该请求中，如果您使用异步调用来查询数据库中的某些数据，您将释放该线程，以便 IIS 可以使用同一线程处理另一个调用。那挺好的。可能吧。
• 一段时间后，当数据库最终提供等待的数据时，代码恢复。异步文档提到您现在可以在另一个线程中。或不。 DotNet 的决定。如果它和以前在同一个线程中，那没关系。
• 我使用依赖注入(inject)在 PerRequest 生命周期中注入(inject)和关闭上下文(使用 Microsoft Unity)。关闭是我在这里的主要关注点。它在我的同步世界中完美运行:dbcontext 在我的网络请求结束时关闭。
• 众所周知，EntityFramework 的 DbContext 不是线程安全的

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

问题2:如果代码运行在另一个线程中，那么WebRequest上下文呢？ DI 是否会正确跟踪该延迟调用的结束并且在异步代码真正结束之前不调用 Dispose()？

问题 3:如果我使用 EntityFramework 的异步方法，如 ToListAsync 或 FirstOrDefaultAsync，我到处都读到“应该没问题”。有人可以详细说明吗？ EF 是否专门跟踪 Web 请求或初始线程？是否有某种捕获发生？我的 dbcontext 会与另一个重用我的初始线程的 Web 请求混淆吗？

问题 4:如果我使用 EntityFramework 的普通(同步)方法但包装在任务中。会发生什么？还是“应该没问题”？

抱歉，问题太多了，困扰我很久了。

Answer 1

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

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

Yes - all threads come from the thread-pool. Your MVC app is already multi-threaded, when a request comes in a new thread will be taken from the pool and used to service the request. That thread will be 'locked' (from other requests) until the request is fully serviced and completed. If there is no thread available in the pool the request will have to wait until one is available. If you have async controllers they still get a thread from the pool but while servicing the request they can give up the thread, while waiting for something to happen (and that thread can be given to another request) and when the original request needs a thread again it gets one from the pool.

问题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 个任务是不安全的。