Pooling (Singleton) Oggetti contro pool di connessioni

Question

Pooling (Singleton) Oggetti contro pool di connessioni

Naviga le tue risposte

#1 da (1 voti)
#2 da (0 voti)

0

Dato il seguente scenario

Un'applicazione aziendale in scatola che mantiene il proprio pool di connessioni
Un'applicazione client sviluppata internamente all'app aziendale. Questa app è costruita utilizzando il framework Spring, con il pattern DAO

Anche se posso avere una visione semplicistica di questo, penso che la seguente linea di pensiero sia valida:

Avere un pool fisso di oggetti DAO, mantenendo gli oggetti di connessione dal pool. Chiaramente, il pool dovrebbe essere in grado di scalare (o diminuire a seconda delle necessità) e gli oggetti di connessione devono superare numericamente i DAO con un margine salutare. Buono
Creazione di nuovi DAO nuovi di zecca per ogni richiesta di accesso all'app aziendale; ogni DAO tenterà di prendere una connessione dal pool e rilasciarlo quando è fatto. Bad

Poiché si tratta di oggetti di servizio, non ci sarà uno stato (mutevole) detenuto dagli oggetti (rischio ridotto di problemi di concorrenza)

Penso anche che con # 1, ci dovrebbe essere poca o nessuna contesa di risorse, mentre in # 2, ci sarà quasi sempre un DAO in attesa di essere servito. Il mio pensiero è corretto e cosa potrebbe andare storto?

dependency-injection spring

posta kolossus 10.04.2014 - 15:19

fonte

2 risposte

Leggi altre domande sui tag dependency-injection spring

Priorità degli abbonati degli array Interfaccia utente della console Rich

score 1 · Answer 1

Entity Framework e Linq to SQL entrambi istanziano DAO come necessario.

I DAO in Entity Framework (sono chiamati contesti dati) sono progettati appositamente per essere leggeri da istanziare, quindi ne crei uno nuovo ogni volta che è necessario un accesso ai dati. A volte le persone cercano di memorizzare nella cache questi contesti dati, ma si tratta di un errore di progettazione e possono causare problemi di concorrenza ( DataContext non è thread-safe). In generale, crei un oggetto DataContext per ogni Unità di lavoro.

Entity Framework è più comunemente usato con SQL Server; SQL Server gestisce un pool di "connessioni utilizzate di recente" che possono essere riutilizzate, in modo che il processo di apertura di una nuova connessione sia il più veloce possibile.

Ulteriori letture
Linq a SQL DataContext Lifetime Management
Creazione di applicazioni N-Tier con Entity Framework ... per vari approcci.

score 0 · Answer 2

Oltre all'intuizione pratica della risposta di Robert Harvey, penso che sia importante tenere a mente il quadro generale, entrambi gli schemi stanno facendo cose equivalenti. Ci sarà una sorta di accodamento, indipendentemente dallo schema che scegli. La differenza sarà dove vive quella logica. Se esiste una contesa di risorse con la fornitura di connessioni a oggetti DAO, ci sarebbe stata una contesa di risorse con l'assegnazione di un oggetto DAO al proprio consumatore.