Memorizzazione di una connessione JDBC in HttpSession

Question

Ho recentemente ereditato del codice, all'interno del quale ho trovato una connessione JDBC inizializzata in un filtro e aggiunta la HttpSession per ogni utente. Tale connessione viene quindi riutilizzata in varie parti dell'applicazione Web per l'utente. Questo mi è apparso immediatamente come un odore di codice. Mi piacerebbe tornare dallo sviluppatore che lo ha scritto e spiegare perché non dovrebbe farlo ... Ma forse non sono così sicuro di me stesso ...

Oltre a occupare spazio inutile nella memoria e potenzialmente limitando le connessioni disponibili al database, ci sono altri motivi per cui non si memorizzerebbe una connessione JDBC in una sessione?

Answer 1

Hai menzionato l'ovvio, una connessione di un utente a un database non è scalabile. Gli utenti dovrebbero essere completamente disaccoppiati dall'accesso al modello di dati. Qui ci sono un paio di problemi in cui ti imbatterai.

• Cosa succede se la connessione diventa obsoleta? Quell'utente non sarà in grado di fare nulla di utile senza una connessione al database, quindi probabilmente dovranno disconnettersi e poi rientrare per ottenere una nuova connessione. pazza.
• I collegamenti JDBC non sono thread-safe. Se un utente decide di gestire un paio di cose contemporaneamente, si scatenerà l'inferno.

Answer 2

L'idea di mantenere le connessioni JDBC in alto nello stack come in HttpSession o persino l'accesso alle connessioni JDBC sul livello del servlet non ha molto senso. È molto più sensato raggruppare le connessioni sul server delle applicazioni e ridurre la quantità di connessioni aperte in questo modo. La stessa applicazione è quindi in grado di servire molti più utenti simultanei con prestazioni molto migliori.

In un'applicazione di grandi dimensioni è improbabile che tutte le richieste raggiungano il database poiché è probabile che le stesse informazioni vengano comunque trovate nella cache.

In ambiente cluster con sessioni non appiccicose, la connessione JDBC non sarebbe nemmeno valida se la richiesta colpisse una casella diversa da quella in cui è stata creata la sessione.

In generale, è necessario memorizzare solo le informazioni specifiche dell'utente nella sessione e persino ridurre al minimo l'importo necessario nelle sessioni. Più dati in sessione significa più dati da trasferire tra i server delle applicazioni in un cluster quando le sessioni vengono replicate (nel caso in cui le sessioni non siano archiviate in un DB o in una cache centrale).

Answer 3

Anche se non ho modo di saperlo, mi azzarderei a indovinare che il tuo collega ha iniziato con ogni richiesta recuperando una nuova connessione dal gestore, proprio come è stato fatto nei programmi per principianti e demo. Ben presto scoprì che questa richiesta rallentava drasticamente; quindi ora evita la creazione di connessioni "raggruppandole" nelle sessioni utente.

Questo risolve il problema di prestazioni per gli utenti che effettuano una seconda e successive richieste su una connessione, ma è una soluzione molto scomoda e non scalabile. Se la base utenti della tua applicazione cresce, il numero di utenti con sessioni aperte supererà rapidamente il numero massimo di connessioni che il DB può darti. E poi ci sono problemi con le sessioni o le connessioni DB che scadono ...

La soluzione "standard di settore" consiste nell'utilizzare il pool di connessioni. Le versioni moderne di Tomcat dispongono del pool di connessioni "integrato", così come altri server di applicazioni Web. In caso contrario, puoi installare facilmente la tua. Ciò consente di gestire un pool di connessioni in modo completamente indipendente dalle sessioni utente.

Un altro vantaggio del pool di connessioni è che, una volta che il pool è "riscaldato", vale a dire.un certo numero di connessioni sono in uso e inizializzate, anche le "prime richieste per sessione utente" ricevono rapidamente una connessione. Quindi il throughput complessivo sarà migliorato rispetto alla situazione attuale.