Ich weiß, dass dies eine ziemlich allgemeine Frage, aber bitte mit mir tragen:EntityFramework Core-loadbalanced
Ich stolperte gerade über die EntityFramework Cache aka Change.
Was wir haben, ist ein kleiner Microservice mit Netzkern mit Entity-Core. Dieser Microservice ist loadbalanced (RoundRobin) hinter einem IIS (soweit ich nichts erraten kann). Lassen Sie uns sie Instance1 und Instance2 nennen.
Was passiert nun:
ich einen Eintrag in der db haben, zum Beispiel (dargestellt als JSON hier der Einfachheit halber):
{ Name: "Test", FirstName: "T." }
Jetzt lade ich diese in eine Form (Antwort aus Instance1) und modifiziere den FirstName zu Thomas und speichere ihn über ein PUT, was von Instance2 erledigt wird. Jetzt mache ich eine weitere Anfrage, um diesen Eintrag zu bekommen. Diese Anfrage wird von Instance1 beantwortet, die diese aus dem Cache lädt (da der Changetracker sagt, dass sie unverändert ist). Und so komme ich
{Name: "Test", FirstName: "T."}
Es scheint, dass viele Leute zu sein, die Probleme mit der Änderung Tracker und einer gemeinsamen Antwort ist den DbContext mit jeder Anfrage neu zu erstellen, die völlig falsch ich scheint, denn dies ist ein sehr "teure" Operation.
Auch habe ich festgestellt, dass das Einfügen von neuen Daten mit der Zeit immer langsamer wird, weil der Change Tracker sich füllt, also müsste ich den Microservice immer und immer wieder recyceln.
Also meine Frage ist: Wie kann ich dieses Problem umgehen, ohne den dbcontext bei jeder Anfrage neu zu initialisieren? Ich fand auch einige Antworten, die das Caching deaktivieren, aber nur für eine einzige db-Operation, was bedeutet, dass ich diese Option zu jeder DB-Operation hinzufügen müsste, was für mich fast genauso falsch ist wie die Reinitialisierung des Db-Kontextes bei jeder Anfrage . Was habe ich übersehen, es muss eine einfache Lösung geben!
Ich glaube, Sie sollten nicht als Cache-Mechanismus der Änderung Tracker denken. Es wird genau zum Verfolgen von Änderungen pro DB-Kontext verwendet. Verwenden Sie einen neuen db-Kontext pro Anfrage, was meiner Meinung nach die richtige Wahl ist. Wenn Sie einen Cache benötigen, verwenden Sie den db-Kontext für diesen Zweck nicht, verwenden Sie beispielsweise memcache oder das Build-in für .net System.Runtime.Caching. Natürlich müssen Sie den Cache weiterhin mit der Datenbank synchronisieren, aber Ihr Datenbankkontext wird nicht mit überprüften (nicht synchronisierten) Entitäten aufgebläht. Btw Erstellen neuer Db-Kontext ist sehr billig/leichte Operation, weil es einen Verbindungspool dahinter ist. –
Ja, Sie haben es ernsthaft vermasselt. DbContext muss auf einen Bereich beschränkt sein (eine Instanz pro Anfrage), was das Standardverhalten ist. Du musst es irgendwo als Singleton haben. Verwenden Sie besser Redis oder etwas ähnliches für die Verteilung von Caching – Tseng
Nun, ich injiziere den Db-Kontext in mein Repository. Mein Repo wird in den Controller injiziert, aber als Singleton, so scheint es, dass dies mein Fehler ist. Wenn ich mein Repository ein Scoped mache, sollte es mit jeder Anfrage erstellt werden, und dann auch einen neuen db-Kontext in es einfügen? Ich werde das morgen versuchen, danke für Ihre Ansers! – PWFraley