在我的情况下，问题发生是因为依赖注入注册。我正在将每个请求范围的服务注入到一个单例注册服务中，该服务使用dbcontext。因此在多个请求中使用了dbcontext，因此出现了错误。

在我的情况下，问题发生是因为依赖注入注册。我正在将每个请求范围的服务注入到一个单例注册服务中，该服务使用dbcontext。因此在多个请求中使用了dbcontext，因此出现了错误。

通过向构造函数中添加选项，我轻松地(实用地)解决了这个问题。因此，我只在需要时使用它。

public class Something : DbContext
{
    public Something(bool MultipleActiveResultSets = false)
    {
        this.Database
            .Connection
            .ConnectionString = Shared.ConnectionString /* your connection string */
                              + (MultipleActiveResultSets ? ";MultipleActiveResultSets=true;" : "");
    }
...

这个问题可以简单地通过将数据转换为列表来解决

 var details = _webcontext.products.ToList();


            if (details != null)
            {
                Parallel.ForEach(details, x =>
                {
                    Products obj = new Products();
                    obj.slno = x.slno;
                    obj.ProductName = x.ProductName;
                    obj.Price = Convert.ToInt32(x.Price);
                    li.Add(obj);

                });
                return li;
            }

我最初决定在我的API类中使用一个静态字段来引用MyDataContext对象的实例(其中MyDataContext是一个EF5 Context对象)，但这似乎是造成问题的原因。我在每个API方法中都添加了如下代码，从而解决了这个问题。

using(MyDBContext db = new MyDBContext())
{
    //Do some linq queries
}

正如其他人所说，EF数据上下文对象不是线程安全的。因此，在适当的条件下，将它们放置在静态对象中最终会导致“数据读取器”错误。

我最初的假设是只创建对象的一个实例会更有效，并提供更好的内存管理。从我研究这个问题所收集到的资料来看，情况并非如此。事实上，将对API的每个调用视为一个独立的线程安全事件似乎更有效。确保当对象超出作用域时，所有资源都被适当释放。

这是有意义的，特别是如果你把你的API带到下一个自然的进程，即将它公开为WebService或REST API。

信息披露

操作系统:Windows Server 2012 .NET:安装4.5，项目使用4.0 数据来源:MySQL 应用程序框架:MVC3 身份验证:形式

在第二次查询之前，我使用以下代码段解决了这个问题:

 ...first query
 while (_dbContext.Connection.State != System.Data.ConnectionState.Closed)
 {
     System.Threading.Thread.Sleep(500);
 }
 ...second query

您可以以毫秒为单位更改睡眠时间

P.D.在使用线程时很有用