web-dev-qa-db-fra.com

Entity Framework "Exception de connexion inattendue"

Après trois heures de débogage et de recherche, j'espère que quelqu'un ici aura une réponse. Entity Framework (à l'aide de MySQL) lève l'exception suivante si j'appelle rapidement la fonction suivante successivement (par exemple <0,1 seconde à part).

System.InvalidOperationException: état de connexion inattendu. Lorsque vous utilisez un fournisseur de wrapping, assurez-vous que l'événement StateChange est implémenté sur le DbConnection encapsulé.

Cependant, la fonction fonctionne parfois sans aucun problème. L'exception est levée lors du premier appel ToList():

void InsertOrUpdateMaterials(List<Material> materials)
{
    var id = GetUserId();
    var materialIds = materials.Select(x => x.MaterialId).ToList();

    // Remove old materials from DB
    var oldMaterials = Db.Materials.Where(p => p.CreatedBy == id && 
            materialIds.Contains(p.MaterialId)).ToList(); // exception
    Db.Materials.RemoveRange(oldMaterials);
    Db.SaveChanges();

    // Replace previous materials with the new ones in list
    Db.Materials.AddRange(materials);
    Db.SaveChanges();
}

Bizarrement, cette erreur ne s’est jamais produite sur le serveur de développement, j’ai donc cherché en vain des problèmes de configuration.

Parfois, Entity Framework renvoie:

System.Data.Entity.Core.EntityCommandExecutionException: un DataReader ouvert associé à cette connexion doit déjà être fermé.

Encore une fois pointant vers l'appel ToList(). Des idées?

c#entity-frameworksignalr
17
arao6

Pour d'autres personnes qui pourraient avoir un problème similaire. D'après les commentaires ci-dessus, il semble que le code utilise un contexte de base de données mis en cache. Après la création du contexte de base de données, la connexion de base de données est rompue (aucun gestionnaire StateChangehandler n'a été installé dans l'application). Après la rupture de la connexion, l’application a utilisé le contexte de base de données mis en cache pour effectuer certaines opérations.

La création d'un nouveau contexte de base de données a résolu le problème.

4
Moerwald

J'ai eu ce problème avec Effort.EF6 1.3.0. Le correctif pour moi était de mettre à jour la dépendance NMemory de 1.1.0 à 1.1.2.

1
user326608

J'ai eu le même problème en utilisant Effort.EF6, mais la mise à jour de NMemory (comme user326608 suggéré) n'a pas aidé. Il s'avère que XUnit exécute des tests en parallèle par défaut depuis V2 .

Désactiver ce comportement a résolu le problème pour moi. Ajoutez les éléments suivants à AssemblyInfo.cs:

using Xunit;
[Assembly: CollectionBehavior(CollectionBehavior.CollectionPerAssembly)]

Bien que je considère cela comme une solution de contournement, les tests unitaires doivent être indépendants les uns des autres.

0
markbeij