Che cos'è un buon strumento per l'analisi dell'utilizzo di Database Connection in Java?

Question

Che cos'è un buon strumento per l'analisi dell'utilizzo di Database Connection in Java?

Uno sviluppatore supporta un complesso programma Java che sta occasionalmente estenuando il numero di connessioni Database disponibili. Poiché il problema è sporadico, sarebbe utile sapere quale thread ha aperto più connessioni al database per concentrare gli sforzi in quest'area.

Alla fine, la correzione corretta sembra essere quella di riscrivere il programma per riutilizzare le connessioni e non aprire più connessioni per thread.

Mi chiedo, quali strumenti deve avere lo sviluppatore nella sua casella degli strumenti per poter esaminare le risorse, ad esempio le connessioni di database assegnate da un thread.

Answer 1

Non uno strumento specifico, ma piuttosto una tecnica di debug per rintracciare quale codice è responsabile per le connessioni aperte o altre risorse.

Suppongo che si stia utilizzando un metodo coerente sul lato java per ottenere una connessione db (raggruppata o meno non importa).

L'idea è di creare una classe wrapper molto leggera attorno al tuo factory/pool di connessione o qualunque cosa sia.Il wrapper implementerà qualsiasi interfaccia jdbc ha senso in modo da poterlo scambiare per il normale oggetto di connessione, ma la maggior parte dei metodi chiamerà/restituirà la connessione sottostante in modo trasparente.

Se si utilizza una sorta di framework IoC (ad esempio la primavera) si dovrebbe essere in grado di scambiare facilmente la connessione/factory class a un livello di configurazione. Ora tutto il tuo codice java utilizzerà il tuo nuovo wrapper di connessione db.

Se si sta utilizzando un pool, chiamare connection.close() in genere restituisce l'oggetto al pool anziché distruggere la connessione. Quindi questa tecnica funziona per perdite di connessione normali o perdite "non restituite al pool (pool esaurito)".

Ora dobbiamo solo registrare i bit interessanti e impostare una trappola per le connessioni trapelate.

Stack trace per identificare creatore

Nel costruttore o il metodo factory per il vostro involucro di connessione creare un nuovo oggetto Throwable e conservarlo come variabile locale all'interno del vostro involucro per più tardi. Usiamo un Throwable perché è più veloce/economico rispetto all'utilizzo di Thread.currentThread().getStackTrace().

Impostare la "trappola"

implementare il metodo finally nella classe wrapper. Questo è un metodo di pulizia chiamato dal GC quando l'oggetto viene distrutto perché non viene più utilizzato.

Il metodo finally deve verificare "sono chiuso?". Se è già chiuso, allora è tutto a posto ... tuttavia se la connessione è in GC e non è stata chiusa ... allora questa è una connessione "perduta".

Ora il Throwable ritorna in gioco. Siamo in grado di afferrare il Throwable e di produrre un bel messaggio di registro che dice qualcosa del tipo: "Sono una connessione trapelata e qui c'è una traccia dello stack che coinvolge il mio creatore".

Espandendo l'idea

Questo metodo può essere adattato per una varietà di situazioni. Puoi naturalmente conservare altri tipi di dati nel tuo wrapper per risolvere il tuo problema specifico. Ad esempio il tempo di creazione. Quindi puoi eseguire il polling per connessioni a lunga durata e coinvolgere nuovamente il creatore. Oppure puoi eseguire il polling delle connessioni esistenti e analizzare le tracce dello stack Throwable per ottenere dati su quale codice sta utilizzando quante connessioni nel tempo.

Probabilmente esiste uno strumento standard che può anche fare questo tipo di cose, ma la quantità di codice richiesta per applicare questa tecnica è molto minima nella maggior parte dei casi (presupponendo che tu abbia un modo semplice per scambiare il tuo db connection factory senza search-replaceing dell'intera codebase).

Answer 2

Dai un'occhiata allo log4jdbc. Ti permette di dare un'occhiata a tutte le cose che vanno su jdbc, comprese le connessioni di apertura/chiusura e le informazioni sul numero di connessione.

Answer 3

I pool di connessione possono fornire alcuni strumenti diagnostici. Per esempio controllare immobili debugUnreturnedConnectionStackTraces per pool di connessione C3P0:

http://www.mchange.com/projects/c3p0/index.html#debugUnreturnedConnectionStackTraces

Answer 4

Qualcuno mi ha mostrato ConnLeakFinder di recente "uno strumento semplice per individuare le perdite di connessione JDBC in codice Java". Non l'ho ancora provato personalmente ma dovrebbe permetterti di vedere Per vedere chi non ha chiuso la connessione dopo l'uso. Vedi Connection+Leak+How+To+Find.htm.

Tuttavia, si consiglia di utilizzare un pool di connessioni (ad esempio c3p0).

Answer 5

P6Spy è un framework open source per supportare applicazioni che intercettano ed eventualmente modificano le istruzioni del database.

Da http://www.p6spy.com/about.html
distributiva P6Spy include i seguenti moduli:

• P6Log. P6Log intercetta e registra le dichiarazioni del database di qualsiasi applicazione che utilizza JDBC. Questa applicazione è particolarmente utile per gli sviluppatori per monitorare le istruzioni SQL prodotte dai server EJB, consentendo allo sviluppatore di scrivere codice che raggiunge la massima efficienza sul server. P6Spy è progettato per essere installato in pochi minuti e non richiede modifiche al codice.
• P6Outage. P6Outage rileva dichiarazioni di lunga durata che possono essere indicative di un problema di distribuzione del database e registreranno qualsiasi dichiarazione che superi il limite temporale configurabile durante la sua esecuzione. P6Outage è stato progettato per ridurre al minimo qualsiasi penalizzazione delle prestazioni di registrazione registrando solo le istruzioni long running.