ASP.NET MVC5 MySQL - Mehrere DB COntexte sind nach Mutationen nicht mehr synchron

Hallo,

ich habe eine Frage bezüglich der Entities / DbContext.

Ich benutze den System.Data.DbContext, MySQL und Code-First.

Evtl. vorab auch die Frage, ob es überhaupt üblich ist mehrere DbContexte zu haben?

Aktuell habe ich mehrere und da kommt das Problem auf, dass der Inhalt nicht mehr synchron ist, wenn eine Änderung gemacht worden ist - erst wieder wenn ich einen neuen DbContext erzeuge und die Daten frisch aus der Datenbank geholt werden.

Nun die Frage, wie stelle ich das Cachen ab, ohne immer einen neuen DbContext zu erzeugen?

viele Grüße!

Evtl. vorab auch die Frage, ob es überhaupt üblich ist mehrere DbContexte zu haben?

Jedenfalls nicht unüblich; vor allem in größeren Anwendungen.
zB müssen Daten mit unterschiedlichen Sicherheitsstufen gespeichert werden (daher unterschiedliche Datenbanken) oder in einer unterschiedlichen Form (NoSQL vs SQL vs FileSystem).

Aktuell habe ich mehrere und da kommt das Problem auf, dass der Inhalt nicht mehr synchron ist, wenn eine Änderung gemacht worden ist

Das ist dann aber nicht Problem der Datenbank-Contexte.
Halte Dir einen State in der Anwendung; zB mit Reactive Extensions. (Sorry, gilt nicht für Web Anwendungen Server Side).

Was meinst Du hier mit "synchron" ?
Du hast hier ja ohnehin in einer Webanwendung nur die Änderung in einem Request/Response-Verfahren - und pro Request eine Connection zur DB. Wo ist hier etwas "nicht synchron" ?

Hi,

mehrere Contexte sind problemlos möglich wenn man die Daten intelligent anpackt.

Wenn du allerdings an verschiedenen Stellen die selben Daten pro Request anpackst - dann machst du dir natürlich nur Ärger. Allerdings wäre dann in meinen Augen nicht der erste Versuch die Daten frisch abzuholen - sondern den Datenzugriff eher derart zu gestalten, dass man die Daten nicht an verschiedenen Stellen derart anpackt...

LG

Was meinst Du hier mit "synchron" ?
Du hast hier ja ohnehin in einer Webanwendung nur die Änderung in einem Request/Response-Verfahren - und pro Request eine Connection zur DB. Wo ist hier etwas "nicht synchron" ?

Das ist auch richtig, aber wie du mir auch bereits bei den "Jobs" geholfen hast - habe ich hier beispielsweise einen Job der einen Datenbankeintrag manipuliert bzw. auf die Daten zugreift, welche auch über ein Request geändert werden können. Daher würde dieser Job dann mit den alten Daten weiter arbeiten, was ich aber nicht möchte.

Wenn du allerdings an verschiedenen Stellen die selben Daten pro Request anpackst - dann machst du dir natürlich nur Ärger. Allerdings wäre dann in meinen Augen nicht der erste Versuch die Daten frisch abzuholen - sondern den Datenzugriff eher derart zu gestalten, dass man die Daten nicht an verschiedenen Stellen derart anpackt...

Das geht leider nicht aus den oben beschriebenen Grund.

Das ist auch richtig, aber wie du mir auch bereits bei den "Jobs" geholfen hast - habe ich hier beispielsweise einen Job der einen Datenbankeintrag manipuliert bzw. auf die Daten zugreift, welche auch über ein Request geändert werden können.

Sorry, zumindest ich hab das nicht sofort erkannt, dass es hier wieder um die asynchronen Jobs geht.

Daher würde dieser Job dann mit den alten Daten weiter arbeiten, was ich aber nicht möchte.

Da alles asynchron abläuft und Du ohnehin nicht genau weißt, wann der Job genau startet, musst Du in jedem Job die Daten aus der Datenbank abrufen.
Alles andere erzeugt Race Conditions.

Hi,

ich sehe zwar keine Erklärung in diesem Thread warum das nicht geht - aber nach Abt scheint es um asynchrone Jobs zu gehen.

Wenn du Caching/Tracking umgehen möchtest gibt es verschiedene Wege - du kannst dir folgende Seite mal anschauen, falls das mit dem neuen DbContext alleine nicht reicht:
https://codethug.com/2016/02/19/Entity-Framework-Cache-Busting/

LG

Da alles asynchron abläuft und Du ohnehin nicht genau weißt, wann der Job genau startet, musst Du in jedem Job die Daten aus der Datenbank abrufen.
Alles andere erzeugt Race Conditions.

Wie würde man demnach z.B. eine Änderung die über ein Request gekommen ist am besten an einen bereits laufenden Job weitergeben?

Wenn du Caching/Tracking umgehen möchtest gibt es verschiedene Wege - du kannst dir folgende Seite mal anschauen, falls das mit dem neuen DbContext alleine nicht reicht:

>

LG

Auf der Seite war ich auch schon - war sehr hilfreich 😃

Wie würde man demnach z.B. eine Änderung die über ein Request gekommen ist am besten an einen bereits laufenden Job weitergeben?

Ein Job ist i.d.R. isoliert; eine Ineinflussnahme von Außen hört sich irgendwie komisch an.
Warum ist das notwendig?

Du hast vollkommen Recht!
Der Job soll keine Änderungen erhalten - ich hatte lediglich an Abbruchkriterien gedacht.. aber dafür gibts die JobCancellationToken und BackgroundJob.Delete(...).

Dankeschön 😃