Entity Framework: Il y a déjà un DataReader ouvert associé à cette Commande

Il n'est pas à propos de la fermeture de la connexion. EF gère la connexion correctement. Ma compréhension de ce problème est qu'il y a plusieurs récupération des données des commandes exécutées sur un seul type de connexion (ou de commande unique avec de multiples sélectionne) tout en suivant DataReader est exécutée avant la première a terminé la lecture. La seule façon d'éviter l'exception est de permettre à de multiples imbriquées DataReaders = tourner sur MultipleActiveResultSets. Un autre scénario lorsque cela arrive toujours, c'est quand vous itérer résultat de la requête (IQueryable) et vous permettra de déclencher le chargement paresseux pour chargé de l'entité à l'intérieur de l'itération.

Il y a une autre façon de surmonter ce problème. Si c'est une bonne solution dépend de votre situation.

Le résultat de ce problème de chargement paresseux, donc une façon de l'éviter est de ne pas avoir de chargement paresseux, grâce à l'utilisation d'Inclure:

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

Si vous utilisez le Includes, vous pouvez éviter l'activation de MARS. Mais si vous manquez une, vous obtiendrez l'erreur, de sorte que l'activation de MARS est probablement le moyen le plus facile de la corriger.

J'ai résolu le problème facilement (pragmatique) par l'ajout de l'option pour le constructeur. J'ai donc l'utiliser uniquement lorsque cela est nécessaire.

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

J'avais initialement décidé d'utiliser un champ statique dans ma classe de l'API pour faire référence à une instance de MyDataContext objet (Où MyDataContext est un EF5 objet de Contexte), mais c'est ce qui semblait pour créer le problème. J'ai ajouté le code à quelque chose comme à chacun de mes méthodes de l'API et qui a résolu le problème.

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

Que d'autres personnes ont déclaré, l'EF Contexte de Données les objets ne sont PAS thread-safe. Afin de les placer dans l'objet statique qui peut éventuellement causer le "lecteur de données" erreur dans les bonnes conditions.

Mon hypothèse initiale était que la création d'une seule instance de l'objet serait plus efficace, et permettre une meilleure gestion de la mémoire. De ce que j'ai recueillies à la recherche de cette question, qui n'est pas le cas. En fait, il semble être plus efficace pour traiter chaque appel à votre API comme un cas isolé, thread-safe de l'événement. Veiller à ce que toutes les ressources sont correctement libérée, que l'objet est hors de portée.

Cela a un sens, surtout si vous prenez votre API pour la prochaine progression naturelle qui serait à l'exposer comme un Service web ou une API REST.

Divulgation

• Système d'exploitation: Windows Server 2012
• .NET: Installé 4.5, Projet à l'aide de 4.0
• Source De Données: MySQL
• Cadre d'Application: MVC3
• Authentification: Formes

Un bon milieu entre l'activation de MARS et de la récupération de la totalité du jeu de résultats dans la mémoire est d'extraire uniquement les Id dans une requête initiale, et ensuite une boucle sur l'Id de matérialiser chaque entité, comme vous allez.

Par exemple (en utilisant le "Blog et les Messages" échantillon entités comme dans cette réponse):

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

Faire cela signifie que vous tirez de quelques milliers d'entiers en mémoire, par opposition à des milliers de l'ensemble des graphes d'objets, ce qui devrait réduire l'utilisation de la mémoire tout en vous permettant de travailler point par point sans l'activation de MARS.

Une autre belle prestation de cela, comme on le voit dans l'exemple, c'est que vous pouvez enregistrer les modifications que vous en boucle sur chaque élément, au lieu d'avoir à attendre jusqu'à la fin de la boucle (ou tout autre solution de contournement), comme cela serait nécessaire, même avec MARS activé (voir ici et ici).

2 solutions pour pallier à ce problème:

1. De la Force de mise en mémoire cache en gardant le chargement paresseux avec .ToList() après votre
   de la requête, de sorte que vous pouvez ensuite itérer dessus de l'ouverture d'un nouveau DataReader.
2. .Include(/autres entités que vous souhaitez charger dans la requête/) ce
   est appelé désireux de chargement, ce qui vous permet (en effet) comprennent
   associés à des objets(entités) au cours de l'exécution d'une requête avec le
   DataReader.

Si nous essayons de regrouper une partie de nos conditions de travail dans un Func<> ou l'extension de la méthode, nous allons obtenir cette erreur, supposons que nous avons un code comme ceci:

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) { .... }

Ceci lancera l'exception, si nous essayons de l'utiliser dans un cas(), ce que nous devrions faire à la place est de construire un Prédicat comme ceci:

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

De plus, peut être lu à : http://www.albahari.com/nutshell/predicatebuilder.aspx

Dans ma situation, le problème est survenu à cause d'une injection de dépendance de l'enregistrement. J'ai été à injecter un par demande portée de service qui a été à l'aide d'un dbcontext dans un singleton de service déposée. A cet effet le dbcontext a été utilisé dans plusieurs demande et, partant, de l'erreur.