Ho un ruolo di lavoro che funziona con il database ogni secondo.Durata DbContext di Entity Framework nel ruolo di lavoratore
È possibile inizializzare lo DbContext all'avvio del worker e utilizzarlo per tutta la durata dell'operatore?
Come viene gestita la connessione db? Cosa succede se il database passa offline e torna online? Potrò ancora utilizzare il contesto?
Il mio consiglio è di creare, utilizzare e distruggere il contesto per ogni operazione ... non aggrapparsi ad esso. All'inizio mi preoccupavo perché non avevo idea di quanto fosse costoso creare il DbContext, la risposta è, non molto.
Se si tenta di mantenere il riutilizzo di un'istanza DbContext sarà anche incorrere in problemi (molto rapidamente) in quanto è modelli di stato interni inizieranno segnalazione conflitti per le versioni dell'oggetto che sono stati caricati (aggiornati qualunque sia) precedentemente
Accetto questa risposta perché è corretta, ma vedi anche la spiegazione estesa nella mia risposta. – daramasala
Questo articolo suggerisce di configurare DbContext in OnStart() e utilizzare all'interno di Run(): https://azure.microsoft.com/en-gb/documentation/articles/cloud-services-dotnet-get-started/#create-the -l'applicazione-da-zero. Questo non vuol dire che sia corretto, ma solo FYI –
Questo articolo ha a che fare con Azure Cloud Storage da quello che posso vedere, non Entity Framework su un disco locale. Su alcuni sistemi che si occupano di comunicazione di rete, è * possibile * preferibile inizializzare la connessione e mantenerla aperta, ma ciò dipende dalla quantità di handshake che deve essere eseguita (ad esempio, HTTP non funziona in questo modo). Quindi penso che sia necessario fare attenzione a non mescolare concetti qui perché la spina dorsale (e quindi l'operazione) sarà molto diversa tra i due. Saluti, Paul –
Per quanto ne so, l'astrazione principale di DbContext è l'unità di lavoro.
DbContext apre e chiude una connessione db ogni volta che è necessario (ad esempio su context.SaveChanges()) in modo che la connessione db sia irrilevante rispetto all'ambito del contesto.
Guardando in questo modo, ora penso che per decidere quale dovrebbe essere l'ambito dell'istanza DbContext è necessario pensare alla propria unità di lavoro e alle entità che gestisce in memoria.
Per esempio, la mia domanda, di solito non farà senso utilizzando una singola istanza di contesto per tutta la durata del lavoratore perché:
Di solito si lavorerà su soggetti diversi in ogni invocazione ruolo. In questo caso, il contesto dovrà caricare queste entità in memoria comunque.
Overtime, il contesto gestirà sempre più entità in memoria che causeranno problemi di prestazioni (mentre analizza il grafico alla ricerca di modifiche e cose da fare) e alla fine si tradurrà in problemi di memoria.
Mantenere le entità in memoria per un lungo periodo aumenta le probabilità di incoerenze tra le entità nel contesto e i dati effettivi nel db. Risolvere queste incoerenze può costare in termini di prestazioni.
In sintesi, è probabilmente sbagliato usare la stessa DbContext istanza per tutta la durata del ruolo dei lavoratori.
Per decidere sull'ambito di un DbContext pensare in termini di unità di lavoro che si sta implementando.
Troppo ampio, troppo vago. Ci sono due domande in primo luogo. Quindi, il primo dipende in gran parte da cosa fai nel ruolo di lavoratore, da quanti dati, per quanto tempo. Per la seconda domanda si dovrebbe guardare alla resilienza della connessione con Entity Framework. –
@GertArnold La domanda riguarda l'utilizzo di una singola istanza 'DbContext' in un ruolo di lavoro. Le altre domande sono cose a cui sono preoccupato in questo senso. "per quanto tempo" - "per tutta la vita del lavoratore". Ciò significa dall'avvio della macchina virtuale all'arresto della VM, no? "resilienza della connessione" - stai dicendo che una perdita di connessione è un errore temporaneo e verrà gestita dalla logica del tentativo? – daramasala