2009-12-08 16 views
7

Ho impostato tomcat per utilizzare un pool di connessioni, ma dopo il timeout mysql sulle connessioni le connessioni precedentemente aperte nel pool non sono aperte. Ecco come appare il mio file context.xml:JDBC Pool di connessione non riaperto Connections in tomcat

<Resource name="jdbc/hpsgDB" auth="Container" type="javax.sql.DataSource" 
      maxActive="5" maxIdle="3" maxWait="10000" 
      username="uname" password="password" driverClassName="com.mysql.jdbc.Driver" 
      url="jdbc:mysql://localhost:3306/hpsgdb?autoReconnect=true"/> 

come potete vedere ho incluso Autoreconnect come vero ma non è così. Ho controllato il processo sul database dopo 8 ore, che è l'impostazione del timeout. Se qualcuno può aiutare, per favore aiutatemi visto che questo è stato un problema per alcuni mesi, ma è appena spuntato come urgente a causa del fatto che il mio software potrebbe essere presto disponibile.
Grazie in anticipo Dean Chester

risposta

6

Provare ad aggiungere un attributo di query di convalida. Questo dovrebbe avere l'effetto di chiusura automatica e riaprendo la connessione dopo un timeout come questo:

validationQuery="SELECT 1" 
+0

ho ottenuto questa soluzione su un altro forum partecipavano e già l'ho fatto. Convalida – Dean

+0

Query non è sufficiente. Per favore leggi: http://leakfromjavaheap.blogspot.com/2013/11/robust-db-connection-pool-configuration.html –

+0

Le proprietà 'testWhileIdle' e' test-on-borrow' useranno validationQuery –

1

Dal momento che questo è urgente e per la produzione vi suggerisco di avere un'occhiata a un pool di connessione decente, come c3p0. È più robusto e affidabile e può gestire meglio i timeout.

5

Innanzitutto, eliminare la proprietà autoReconnect. Non hai bisogno di questo con un pool di connessioni e potresti causare problemi.

In secondo luogo, in modo che si vicino tutte le risorse (Connection, Statement e ResultSet) nel codice JDBC nel blocco finally.

Non sono sicuro se questo si applica nel tuo caso, ma un malinteso comune tra i principianti è che sembrano pensare che non è necessario chiudere tali risorse in caso di connessioni in pool. Questo non è vero. Una connessione in pool è un wrapper (decoratore) attorno ad un collegamento che ha un close() metodo leggermente cambiato, che grosso modo simile

public void close() throws SQLException { 
    if (this.connection is still active) { 
     do not close this.connection, but just return it to pool for reuse; 
    } else { 
     actually invoke this.connection.close(); 
    } 
} 

Con altre parole, chiudendo loro consente di liberare la connessione in pool in modo che possa essere rimesso in piscina per il futuro riutilizzo. Se si acquisiscono connessioni senza chiuderle, il pool si esaurirà prima o dopo le connessioni.

0

Con la configurazione, non è necessario creare un'altra connessione se è inattiva. Prova ad aggiungere

minIdle="3" 

Con questa impostazione, DBCP manterrà 3 connessioni tutte le volte.

Vediamo esattamente lo stesso comportamento con uno dei server leggermente utilizzati. A causa del timeout di connessione predefinito di 8 ore, non vediamo connessioni quando arriviamo al mattino. Questo è quello che ci aspettavamo. Tuttavia, a volte vediamo una connessione obsoleta e la prima richiesta non riuscirà. Per ovviare a questo problema, è necessario aggiungere i seguenti attributi,

testWhileIdle="true", 
timeBetweenEvictionRunsMillis="60000" 
Problemi correlati