Estrutura de entidades: já existe um DataReader aberto associado a este comando

Estou usando o Entity Framework e, ocasionalmente, recebo esse erro.

EntityCommandExecutionException
{"There is already an open DataReader associated with this Command which must be closed first."}
   at System.Data.EntityClient.EntityCommandDefinition.ExecuteStoreCommands...

Mesmo que eu não esteja fazendo nenhum gerenciamento de conexão manual.

esse erro ocorre intermitentemente.

código que aciona o erro (abreviado para facilitar a leitura):

        if (critera.FromDate > x) {
            t= _tEntitites.T.Where(predicate).ToList();
        }
        else {
            t= new List<T>(_tEntitites.TA.Where(historicPredicate).ToList());
        }

usando Dispose pattern para abrir sempre uma nova conexão.

using (_tEntitites = new TEntities(GetEntityConnection())) {

    if (critera.FromDate > x) {
        t= _tEntitites.T.Where(predicate).ToList();
    }
    else {
        t= new List<T>(_tEntitites.TA.Where(historicPredicate).ToList());
    }

}

ainda problemático

por que a EF não reutilizaria uma conexão se ela já estiver aberta.

Não se trata de fechar a conexão. A EF gerencia a conexão corretamente. Meu entendimento desse problema é que existem vários comandos de recuperação de dados executados em conexão única (ou comando único com várias seleções) enquanto o próximo DataReader é executado antes que o primeiro conclua a leitura. A única maneira de evitar a exceção é permitir vários DataReaders aninhados = ativar MultipleActiveResultSets. Outro cenário em que isso sempre acontece é quando você itera pelo resultado da consulta (IQueryable) e aciona o carregamento lento da entidade carregada na iteração.

Como alternativa ao uso do MARS (MultipleActiveResultSets), você pode escrever seu código para não abrir vários conjuntos de resultados.

O que você pode fazer é recuperar os dados na memória, para que você não abra o leitor. Isso geralmente é causado pela iteração em um conjunto de resultados ao tentar abrir outro conjunto de resultados.

Código de amostra:

public class MyContext : DbContext
{
    public DbSet<Blog> Blogs { get; set; }
    public DbSet<Post> Posts { get; set; }
}

public class Blog
{
    public int BlogID { get; set; }
    public virtual ICollection<Post> Posts { get; set; }
}

public class Post
{
    public int PostID { get; set; }
    public virtual Blog Blog { get; set; }
    public string Text { get; set; }
}

Vamos dizer que você está fazendo uma pesquisa em seu banco de dados contendo estes:

var context = new MyContext();

//here we have one resultset
var largeBlogs = context.Blogs.Where(b => b.Posts.Count > 5); 

foreach (var blog in largeBlogs) //we use the result set here
{
     //here we try to get another result set while we are still reading the above set.
    var postsWithImportantText = blog.Posts.Where(p=>p.Text.Contains("Important Text"));
}

Podemos fazer uma solução simples para isso adicionando .ToList () assim:

var largeBlogs = context.Blogs.Where(b => b.Posts.Count > 5).ToList();

Isso força o framework de entidade a carregar a lista na memória; portanto, quando iteramos no loop foreach, ele não está mais usando o leitor de dados para abrir a lista, mas sim na memória.

Sei que isso pode não ser o desejado se você deseja carregar preguiçosamente algumas propriedades, por exemplo. Este é principalmente um exemplo que, com sorte, explica como / por que você pode ter esse problema, para que possa tomar decisões de acordo.

Há outra maneira de superar esse problema. Se é uma maneira melhor, depende da sua situação.

O problema resulta do carregamento lento, portanto, uma maneira de evitá-lo é não ter um carregamento lento, através do uso de Incluir:

var results = myContext.Customers
    .Include(x => x.Orders)
    .Include(x => x.Addresses)
    .Include(x => x.PaymentMethods);

Se você usar os Includes apropriados , poderá evitar ativar o MARS. Mas se você perder um, receberá o erro, portanto, habilitar o MARS é provavelmente a maneira mais fácil de corrigi-lo.

Você recebe esse erro quando a coleção que você está tentando iterar é um tipo de carregamento lento (IQueriable).

foreach (var user in _dbContext.Users)
{    
}

Converter a coleção IQueriable em outra coleção enumerável resolverá esse problema. exemplo

_dbContext.Users.ToList()

Nota: .ToList () cria um novo conjunto sempre e pode causar problemas de desempenho se você estiver lidando com grandes dados.

Resolvi o problema facilmente (pragmático) adicionando a opção ao construtor. Assim, eu uso isso somente quando necessário.

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

Experimente na sua cadeia de conexão para definir MultipleActiveResultSets=true. Isso permite multitarefa no banco de dados.

Server=yourserver ;AttachDbFilename=database;User Id=sa;Password=blah ;MultipleActiveResultSets=true;App=EntityFramework

Isso funciona para mim ... se a sua conexão no app.config ou você a define programaticamente ... espero que seja útil

Originalmente, eu decidi usar um campo estático na minha classe API para fazer referência a uma instância do objeto MyDataContext (Onde MyDataContext é um objeto de Contexto EF5), mas foi isso que pareceu criar o problema. Adicionei código parecido com o seguinte a cada um dos meus métodos de API e isso corrigiu o problema.

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

Como outras pessoas declararam, os objetos EF Data Context NÃO são seguros para threads. Portanto, colocá-los no objeto estático acabará causando o erro "leitor de dados" nas condições corretas.

Minha suposição original era que a criação de apenas uma instância do objeto seria mais eficiente e proporcionaria um melhor gerenciamento de memória. Pelo que reuni pesquisando essa questão, esse não é o caso. De fato, parece ser mais eficiente tratar cada chamada de sua API como um evento isolado e seguro de thread. Garantir que todos os recursos sejam liberados corretamente, pois o objeto sai do escopo.

Isso faz sentido, especialmente se você levar sua API para a próxima progressão natural, que seria expor como API de WebService ou REST.

Divulgação

• SO: Windows Server 2012
• .NET: Instalado 4.5, Projeto usando 4.0
• Fonte de dados: MySQL
• Estrutura de aplicativos: MVC3
• Autenticação: Formulários

Percebi que esse erro ocorre quando envio um IQueriable para a exibição e o uso em um foreach duplo, onde o foreach interno também precisa usar a conexão. Exemplo simples (ViewBag.parents pode ser IQueriable ou DbSet):

foreach (var parent in ViewBag.parents)
{
    foreach (var child in parent.childs)
    {

    }
}

A solução simples é usar .ToList()a coleção antes de usá-la. Observe também que o MARS não funciona com o MySQL.

Eu descobri que tinha o mesmo erro e ocorreu quando eu estava usando um em Func<TEntity, bool>vez de um Expression<Func<TEntity, bool>>para o seupredicate .

Depois que mudei tudo Func'sparaExpression's exceção deixou de ser lançada.

Eu acredito que isso EntityFramworkfaz algumas coisas inteligentes com as Expression'squais simplesmente não se relacionaFunc's

2 soluções para mitigar esse problema:

1. Forçar o armazenamento em cache da memória mantendo um carregamento lento com .ToList() após a consulta, para que você possa iterar através da abertura de um novo DataReader.
2. .Include(/ entidades adicionais que você deseja carregar na consulta /) isso é chamado de carregamento rápido, o que permite (de fato) incluir objetos (entidades) associados durante a execução de uma consulta com o DataReader.

Um bom meio termo entre ativar o MARS e recuperar todo o conjunto de resultados na memória é recuperar apenas IDs em uma consulta inicial e, em seguida, percorrer os IDs que materializam cada entidade à medida que você avança.

Por exemplo (usando as entidades de exemplo "Blog e postagens", como nesta resposta ):

using (var context = new BlogContext())
{
    // Get the IDs of all the items to loop through. This is
    // materialized so that the data reader is closed by the
    // time we're looping through the list.
    var blogIds = context.Blogs.Select(blog => blog.Id).ToList();

    // This query represents all our items in their full glory,
    // but, items are only materialized one at a time as we
    // loop through them.
    var blogs =
        blogIds.Select(id => context.Blogs.First(blog => blog.Id == id));

    foreach (var blog in blogs)
    {
        this.DoSomethingWith(blog.Posts);

        context.SaveChanges();
    }
}

Fazer isso significa que você apenas puxa alguns milhares de números inteiros para a memória, em oposição a milhares de gráficos de objetos inteiros, o que deve minimizar o uso da memória enquanto permite trabalhar item por item sem ativar o MARS.

Outro bom benefício disso, como visto na amostra, é que você pode salvar as alterações à medida que percorre cada item, em vez de ter que esperar até o final do loop (ou alguma outra solução alternativa), conforme seria necessário mesmo com MARS ativado (veja aqui e aqui ).

No meu caso, descobri que faltavam instruções "aguardar" antes das chamadas myContext.SaveChangesAsync (). A adição de espera antes dessas chamadas assíncronas resolveu os problemas do leitor de dados para mim.

Se tentarmos agrupar parte de nossas condições em um método Func <> ou extensão, obteremos esse erro, suponha que tenhamos um código como este:

public static Func<PriceList, bool> IsCurrent()
{
  return p => (p.ValidFrom == null || p.ValidFrom <= DateTime.Now) &&
              (p.ValidTo == null || p.ValidTo >= DateTime.Now);
}

Or

public static IEnumerable<PriceList> IsCurrent(this IEnumerable<PriceList> prices) { .... }

Isso lançará a exceção se tentarmos usá-lo em um Where (), o que devemos fazer é criar um Predicado como este:

public static Expression<Func<PriceList, bool>> IsCurrent()
{
    return p => (p.ValidFrom == null || p.ValidFrom <= DateTime.Now) &&
                (p.ValidTo == null || p.ValidTo >= DateTime.Now);
}

Mais informações podem ser lidas em: http://www.albahari.com/nutshell/predicatebuilder.aspx

Esse problema pode ser resolvido simplesmente convertendo os dados em uma lista

 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;
            }

Na minha situação, o problema ocorreu devido a um registro de injeção de dependência. Eu estava injetando um serviço de escopo por solicitação que estava usando um dbcontext em um serviço registrado singleton. Portanto, o dbcontext foi usado em várias solicitações e, portanto, o erro.

No meu caso, o problema não tinha nada a ver com a cadeia de conexão MARS, mas com a serialização json. Depois de atualizar meu projeto do NetCore2 para 3, recebi esse erro.

Mais informações podem ser encontradas aqui

Resolvi esse problema usando a seguinte seção de código antes da segunda consulta:

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

você pode alterar a hora de dormir em milissegundos

PD Útil ao usar threads