Mehrere dbcontexts in parallele threads, EntityException "Erneut Ihre Aussage, wenn weniger Benutzer aktiv sind,"

Ich bin mit Parallel.ForEach zu tun, die Arbeit auf mehrere threads, mit einer neuen EF5 DbContext für jede iteration, alle eingewickelt in ein TransactionScope, wie folgt:

using (var transaction = new TransactionScope())
{
    int[] supplierIds;

    using (var appContext = new AppContext())
    {
        supplierIds = appContext.Suppliers.Select(s => s.Id).ToArray();
    }

    Parallel.ForEach(
        supplierIds,
        supplierId =>
    {
        using (var appContext = new AppContext())
        {
            Do some work...

            appContext.SaveChanges();                
        }
    });

    transaction.Complete();
}

Nach der Ausführung für ein paar Minuten, es wirft ein EntityException "Der zugrunde liegende Anbieter konnte nicht auf Öffnen ..." mit der folgenden inneren detail:

"Die Instanz von SQL Server Database Engine (Datenbankmodul kann keine LOCK-Ressource erhalten zu dieser Zeit. Erneut Ihre Aussage, wenn weniger Benutzer aktiv sind. Bitten Sie den Datenbankadministrator, um zu überprüfen, die sperren und Speicher-Konfiguration für dieses Beispiel, oder um zu überprüfen, für lang andauernde Transaktionen."

Weiß jemand was dies verursacht oder wie kann es verhindert werden? Danke.

  • Sie sind wahrscheinlich laichen eine Millionen threads, die TPL ist optimiert für kurz -, CPU-gebundene Aufgaben-und nicht CPU-bound-Aufgaben zu verwechseln ("warum gibt es so viel Ersatz-CPU???") in der Laichzeit mehr threads. Verwenden Sie die eingeschränkte Parallelität-scheduler aus der MSDN-Website.
  • msdn.microsoft.com/en-us/library/ee789351.aspx
  • Ich denke, du hast Recht, es war der Laichzeit Lasten von threads. Die Begrenzung der Grad an Parallelität, wie vorgeschlagen, durch bmdixon das problem gelöst.
  • Akzeptierte Antwort geändert 🙂
InformationsquelleAutor Matthew Sharpe | 2013-02-14
  1. 6

    Könnte man auch versuchen Sie, die maximale Anzahl der gleichzeitigen Aufgaben in der Parallel.ForEach() Methode mit new ParallelOptions { MaxDegreeOfParallelism = 8 } (ersetzen 8 mit dem, was Sie wollen, es zu begrenzen,.

    Sehen MSDN für mehr details

    • Das bedeutet nicht, Einfluss auf das, was im Standard-TPL-task-scheduler.
    • Nicht sicher, was du meinst. Parallel.ForEach() nicht erstellen Sie eine Task für jedes Element in der Sammlung, es wiederverwendet Tasks. Und wenn Sie MaxDegreeOfParallelism es wird die Anzahl der Tasks verwendet und damit den tatsächlichen Grad der Parallelität.
    • Es scheint ein problem mit unerwarteten Streitigkeiten in parallele Vorgänge in Entity Framework. Ich habe auch dieses problem erlebt, es wurde auch hier diskutiert: stackoverflow.com/q/13182603/141172
    InformationsquelleAutor bmdixon
  2. 1

    Sollten Sie auch herausfinden, warum Ihre app nimmt so große Mengen von sperren? Sie wickelte eine TransactionScope-um mehrere db-verbindungen. Dies verursacht wahrscheinlich eine verteilte Transaktion, die möglicherweise mit ihm zu tun. Es ist sicherlich verursacht Schlösser nie veröffentlicht, bis zum Schluss. Ändern.

    Können Sie nur sperren Grenzen so weit. Es nicht skaliert, um beliebige Mengen von Lieferanten-ids. Sie müssen feststellen, dass die Ursache für die Schlösser, nicht die Symptome mildern.

    • In der Tat, ich verstehe nicht, warum dies ist die eine Last der Schlösser.
    • Mein Verdacht ist, dass Sie haben 100s der verbindungen gehen zur gleichen Zeit (Sie verstehen?) jeder mit einer "normalen" Menge von Schlössern. Die Lösung ist, verschieben Sie den Transaktionsbereich auf die parallele zum Körper. Versuchen Sie, es zu entfernen, getestet.
    InformationsquelleAutor usr
  3. 0

    Sie die maximale Anzahl der sperren von sql server zugelassen - die standardmäßig automatisch eingestellt und richtet sich nach den verfügbaren Arbeitsspeicher.

    Können Sie

    1. Die Einstellung manuell - habe ich vergessen genau wie, aber google ist dein Freund.
    2. Fügen Sie mehr Arbeitsspeicher, um die sql server -
    3. Verpflichten, Ihre Transaktionen Häufig.
    • Verzeihen Sie meine Unwissenheit, aber ich verstehe nicht, warum das Verfahren erfordert viele Schlösser? Danke für Eure Hilfe.
    • Als usr erwähnt, die Schaffung eines Kontexts innerhalb einer Transaktion Umfang für jedes insert wird in eine große Anzahl von verbindungen, so sind es wahrscheinlich, dass. Tut es zum Absturz, wenn Sie starten Sie Ihren sql-Instanz, bevor es läuft ?
    • Denken Sie darüber etwas mehr, seiner fast sicher, dass. Mit einer einzigen Verbindung und viele Einsätze es würde eskalieren die Schlösser. Mit mehreren verbindungen, kann es nicht tun.
    • Vereinbart. Dank sehr viel!
    • Update: Leider ist die Fehlermeldung Auftritt, auch ohne ein TransactionScope im Ort. Diese etwas untergräbt mein Verständnis der Frage.
    • Sorry, aber ich bin nicht 100% klar ist, was ist es dann. Vielleicht etwas zu tun mit es nicht die Entsorgung der Kontext schnell genug, als seine Durchschleifen ? tun Sie das gleiche mit einem standard-for-Schleife ?
    • Zur info das Problem wurde gelöst, mit bmdixon die Lösung der Einschränkung der Grad der Parallelität. Als ta.speot.vorgeschlagen wird, ich vermute, es war der Laichzeit Lasten der threads, die damit Belastungen der verbindungen.

    InformationsquelleAutor Matt Randle
Schreibe einen Kommentar