La connexion C3P0 n'est pas restaurée après une panne réseau jusqu'au redémarrage du serveur

Question

Nous avons utilisé c3p0 ComboPooledDataSource pour le regroupement de connexions avec Spring JdbcTemplate pour accéder à la base de données Oracle 11g. après un certain temps (il semble après une panne de réseau courte), toute demande d'acquérir une connexion à partir du pool obtiendra une exception de délai d'attente. Ceci ne sera pas résolu avant le redémarrage de notre serveur weblogic (pas besoin de redémarrer le serveur de base de données).

Caused by: com.mchange.v2.resourcepool.TimeoutException: A client timed out while waiting to acquire a resource from com.mchange.v2.resourcepool.BasicResourcePool@a261ecc7 -- timeout at awaitAvailable() 
    at com.mchange.v2.resourcepool.BasicResourcePool.awaitAvailable(BasicResourcePool.java:1317) 
    at com.mchange.v2.resourcepool.BasicResourcePool.prelimCheckoutResource(BasicResourcePool.java:557) 
    at com.mchange.v2.resourcepool.BasicResourcePool.checkoutResource(BasicResourcePool.java:477) 
    at com.mchange.v2.c3p0.impl.C3P0PooledConnectionPool.checkoutPooledConnection(C3P0PooledConnectionPool.java:525) 

J'ai vérifié la base de données sessions en cours ainsi que les journaux c3p0 et il n'y a pas de fuite de connexion (ne sont utilisées que 50 connexions de 1550). J'ai également noté qu'après la coupure du réseau, il n'y aura pas de nouvelle connexion acquise par c3p0 (acquisition_increment est augmentée mais les connexions managées passent de 50 à 10).

Notre configuration de source de données:

<bean id="dataSource" class="com.mchange.v2.c3p0.ComboPooledDataSource" destroy-method="close"> 
     <property name="properties" > 
      <props> 
       <prop key="oracle.net.CONNECT_TIMEOUT">20000</prop> 
       <prop key="oracle.jdbc.ReadTimeout">70000</prop> 
      </props> 
     </property> 
     <!-- Connection properties --> 
     <property name="driverClass" value="oracle.jdbc.driver.OracleDriver"/> 
     <property name="jdbcUrl" value="jdbc:oracle:thin:@//host:port/db_name"/> 
     <property name="user" value="*****"/> 
     <property name="password" value="*****"/> 
     <!-- Pool properties --> 
     <property name="testConnectionOnCheckout" value="true"/> 
     <property name="checkoutTimeout" value="30000" /> 
     <property name="debugUnreturnedConnectionStackTraces" value="true" /> <!-- Turn this on only for debugging --> 
     <property name="preferredTestQuery" value="select 1 from dual"/> 
     <property name="initialPoolSize" value="3" /> 
     <property name="maxAdministrativeTaskTime" value="30" /> 
     <property name="maxIdleTime" value="600" /> 
     <property name="maxPoolSize" value="1550" /> 
     <property name="maxStatements" value="0" /> <!-- Disable statement pooling --> 
     <property name="maxStatementsPerConnection" value="0" /> <!-- Disable statement pooling --> 
     <property name="minPoolSize" value="5" /> 
     <property name="numHelperThreads" value="15" /> 
     <property name="unreturnedConnectionTimeout" value="600" /> <!-- Should set this for debugging leaks --> 
    </bean> 

Je ne sais pas ce qui se passe réellement.

Mise à jour Désolé, la configuration modifiée (test a eu tort de ma question, mais pas dans mon fichier de configuration réelle)

Answer 1

Quelques choses:

1. Vous ne pouvez pas obtenir le test de connexion qui Vous pensez que vous êtes. Vous définissez une propriété appelée TestConnectionOnCheckout, mais le nom de la propriété est testConnectionOnCheckout, avec un minuscule t.
2. Vous pouvez avoir une fuite de connexion. 50 est un nombre curieusement rond de connexions occupées pour quand votre application se fige, et un maxPoolSize de 1550 est sans signification car il est plus élevé que ce que votre back-end prend en charge.
3. Vous êtes configuré avec unreturnedConnectionTimeout et debugUnreturnedConnectionStackTraces pour déboguer les fuites de connexion, mais votre unreturnedConnectionTimeout est très longue. Vous devrez attendre 10 minutes après que les choses se soient figées avant de pouvoir observer (dans vos journaux) les traces de pile de connexions qui ont finalement fui. Envisagez d'en réduire la taille pendant que vous déboguez, de l'ordre de 30 secondes, afin d'obtenir des informations raisonnablement fiables sur les fuites de connexion.

4. Vous avez défini properties, user et password comme valeurs distinctes. Cela pourrait ne pas être si génial. En fin de compte user et password sont définies dans les propriétés JDBC. Si user et password sont définis avant que la propriété properties soit définie, vous risquez de remplacer l'objet de propriétés par des informations d'authentification et de faire des demandes sans mot de passe et utilisateur corrects. Si vous définissez explicitement properties, envisager de le faire avec quelque chose comme ...

   <property name="properties" > 
       <props> 
        <prop key="oracle.net.CONNECT_TIMEOUT">20000</prop> 
        <prop key="oracle.jdbc.ReadTimeout">70000</prop> 
        <prop key="user">*****</prop> 
        <prop key="password">*****</prop> 
       </props> 
   </property> 
   

... vous pouvez donc être sûr que user et password obtenir mis. C3p0 PooledDataSources consigne sa configuration à INFO lors de l'initialisation du pool. Cela peut valoir la peine de regarder cela, et de vérifier que c'est la configuration que vous attendez de voir.