La memorizzazione del pool di connessioni in un singleton è una cattiva pratica?

4

Ho appena letto questa domanda e le richieste di risposta :

"Lets assume db connection object is singleton in my application"

This is a must not. Your database connection MUST NEVER BE (yes, bolded and with capitals to make sure you and every reader never make this mistake) a singleton object. Your Connection con MUST NOT be part of a singleton to keep it open all the time. Instead, use a proper database connection pool that will take care of opening the necessary physical database connections and keep them alive through the live of your application.

Ovviamente usiamo un pool di connessioni per occuparci delle nostre connessioni. Tuttavia, conserviamo questa piscina in un singleton. In quale altro modo si potrebbe garantire che vive in tutta l'applicazione? Le sue cattive pratiche?

    
posta OddDev 01.02.2017 - 11:26
fonte

2 risposte

1

Penso che la risposta citata stia affermando principalmente un parere .

L'unico fatto in quella risposta riguarda l'aspetto "per classloader".

In altre parole: a meno che tu non sia in una situazione, in cui la parte di "molti classloader" arriva non ci sono ragioni tecniche per non usare un singleton.

Naturalmente, l'elemento chiave sarebbe implementare un singleton "corretto"; ad esempio utilizzando un enum Java per questo.

    
risposta data 01.02.2017 - 11:31
fonte
1

Ciò che l'autore della citazione dice è che la connessione non deve mai essere un singleton, non memorizzato in un singleton. Non riesco a immaginare una connessione come un singleton con stato come "connesso", "disponibile", ecc ... I pool sono fatti per questo.

Su un'applicazione faccio la stessa cosa che tu, le connessioni sono memorizzate in un pool tenuto da un singleton, in modo che qualsiasi thread possa usarle.

    
risposta data 01.02.2017 - 12:52
fonte

Leggi altre domande sui tag