Ich habe dies bereits mit einem Speicherprofiler überprüft und es gibt keine echten Entitäten, die im Speicher bleiben aber Hash-Sets, Wörterbücher und EntityKey-Objekte - aber ich habe keine Möglichkeit gefunden, diese Referenzen zu trennen.
So einfache Frage: Wie stoppe ich den Kontext (oder seinen ObjectStateManager) von grenzenlos in der Größe?
[Und ja, ich weiß, dass lange lebende Kontexte vermieden werden sollten, aber in diesem Fall ist es ein komplexer Analyse-Durchlauf, der mehrere hierarchische Daten benötigt, die geladen werden (und das Beispiel unten ist nur ein minimales Problem) es ist ein "kurzer" lebendiger Ein-Operations-Kontext.]
Schritte zu repro:
Code [Aktualisiert, benötigt keine echte DB-Verbindung mehr]:
%Vor%Da ich Entitäten nur direkt nach dem Aufruf von SaveChanges () loslöse, zähle ich jetzt die Anzahl der gelösten Entitäten und wenn der Zähler 10.000 erreicht, entferne ich alle noch lebenden (und benötigten) Objekte aus dem Kontext und erstelle ein neuer Kontext, an den ich alle gelösten Objekte anschließe. Nachteil: Die IsLoaded-Eigenschaft von EntityReferences und EntityCollections ist jetzt immer falsch (aber ich verlasse mich nicht darauf).
Mein Verständnis ist, dass die Trennung den Kontext aus der Entität entfernen soll, nicht die Entität aus dem Kontext. Vertrauen Sie dem Kontext nicht, um Verweise auf Entitäten (oder deren Interna) zu entfernen.
Ich stimme zu, dass das Lecken ein Problem ist, aber viele Leute (ich selbst eingeschlossen) haben versucht und es versäumt zu verhindern, dass EF-Kontexte unbegrenzt wachsen (solange Abfragen ausgeführt werden).
Als vorgeschlagene Lösung könnte es vielleicht möglich sein, die Datenbankstruktur in Ihrer eigenen In-Memory-Repräsentation neu zu erstellen, daran zu arbeiten und dann wieder in die Datenbank zu konvertieren, anstatt sich auf die Datenbank als "Arbeitsraum" für Ihre Berechnungen zu verlassen db. Sie können temporäre Dateien verwenden, wenn Sie viele Daten haben.
Dies sollte die Lebensdauer von Kontexten verkürzen.
Alternativ können Sie auch etwas anderes als EF (zumindest für die bearbeitungsintensiven Teile) verwenden, da es für Ihre Situation möglicherweise nicht geeignet ist. Vielleicht wäre etwas niedrigeres Niveau wie ein DataReader für Ihre Situation besser geeignet.
Tags und Links memory-leaks .net c# entity-framework