preferredTestQuery ne jamais utiliser avec c3p0 0.9.5.2 et Tomcat 7

Question

J'utilise tomcat7 avec c3p0-0.9.5.2 et postgresql-9.3-1102-jdbc41, le preferredTestQuery (select 1) n'est jamais utilisé, dans le produit seulement.

La même configuration fonctionne correctement dans test env (vérifiez avec la requête de mise à jour).

Dans le produit, il y a beaucoup d'appels à la requête getTable postgresql. (> 1000cpm - données New Relic).

<Resource name="jdbc/database_read_only" 
      auth="Container" 
      type="com.mchange.v2.c3p0.ComboPooledDataSource" 
      description="Ma description" 
      jdbcUrl="jdbc:postgresql://hostname:5432/mabase" 
      driverClass="org.postgresql.Driver" 
      user="monuser" 
      password="monpassword" 
      initialPoolSize="10" 
      minPoolSize="10" 
      maxPoolSize="100" 
      acquireIncrement="10" 
      maxIdleTime="300" 
      maxConnectionAge="1800" 
      connectionTesterClassName="com.mchange.v2.c3p0.impl.DefaultConnectionTester" 
      preferredTestQuery="select 2" 
      testConnectionOnCheckout="true" 
      testConnectionOnCheckin="false" 
      idleConnectionTestPeriod="300" 
      maxIdleTimeExcessConnections="60" 
      unreturnedConnectionTimeout="10" 
      factory="org.apache.naming.factory.BeanFactory"/> 

Le journal semble bien:

2016-12-23 15:26:10,138 : Initializing c3p0 pool... com.mchange.v2.c3p0.ComboPooledDataSource [ acquireIncrement -> 10, acquireRetryAttempts -> 30, acquireRetryDelay -> 1000, autoCommitOnClose -> false, automaticTestTable -> null, breakAfterAcquireFailure -> false, checkoutTimeout -> 0, connectionCustomizerClassName -> null, connectionTesterClassName -> com.mchange.v2.c3p0.impl.DefaultConnectionTester, contextClassLoaderSource -> caller, dataSourceName -> ddsdsdsqd, debugUnreturnedConnectionStackTraces -> false, description -> ma description, driverClass -> org.postgresql.Driver, extensions -> {}, factoryClassLocation -> null, forceIgnoreUnresolvedTransactions -> false, forceSynchronousCheckins -> false, forceUseNamedDriverClass -> false, identityToken -> mytoken, idleConnectionTestPeriod -> 300, initialPoolSize -> 10, jdbcUrl -> jdbc:postgresql://hostname:5432/monapp, maxAdministrativeTaskTime -> 0, maxConnectionAge -> 1800, maxIdleTime -> 300, maxIdleTimeExcessConnections -> 60, maxPoolSize -> 100, maxStatements -> 0, maxStatementsPerConnection -> 0, minPoolSize -> 10, numHelperThreads -> 3, preferredTestQuery -> select 1, privilegeSpawnedThreads -> false, properties -> {user=******, password=******}, propertyCycle -> 0, statementCacheNumDeferredCloseThreads -> 0, testConnectionOnCheckin -> false, testConnectionOnCheckout -> true, unreturnedConnectionTimeout -> 0, userOverrides -> {}, usesTraditionalReflectiveProxies -> false ] 

Pourquoi demande c3p0 utilisation et non de complexe "sélectionnez 1"?

échantillon de complexe requete:

SELECT * FROM (SELECT n.nspname,c.relname,a.attname,a.atttypid,a.attnotnull OR (t.typtype = 'd' AND t.typnotnull) AS attnotnull,a.atttypmod,a.attlen,row_number() OVER (PARTITION BY a.attrelid ORDER BY a.attnum) AS attnum, pg_catalog.pg_get_expr(def.adbin, def.adrelid) AS adsrc,dsc.description,t.typbasetype,t.typtype FROM pg_catalog.pg_namespace 

SELECT NULL AS TABLE_CAT, n.nspname AS TABLE_SCHEM, c.relname AS TABLE_NAME, CASE n.nspname ~ '^pg_' OR n.nspname = 'information_schema' WHEN true THEN CASE WHEN n.nspname = 'pg_catalog' OR n.nspname = 'information_schema' THEN CASE c.relkind WHEN 'r' THEN 'SYSTEM TABLE' WHEN 'v' THEN 'SYSTEM VIEW' WHEN 'i' THEN 'SYSTEM INDEX' ELSE NULL END WHEN n.nspname = 'pg_toast' THEN CASE c.relkind WHEN 'r' THEN 'SYSTEM TOAST TABLE' WHEN 'i' THEN 'SYSTEM TOAST INDEX' ELSE NULL END ELSE CASE c.relkind WHEN 'r' THEN 'TEMPORARY TABLE' WHEN 'i' THEN 'TEMPORARY INDEX' WHEN 'S' THEN 'TEMPORARY SEQUENCE' WHEN 'v' THEN 'TEMPORARY VIEW' ELSE NULL END END WHEN false THEN CASE c.relkind WHEN 'r' THEN 'TABLE' WHEN 'i' THEN 'INDEX' WHEN 'S' THEN 'SEQUENCE' WHEN 'v' THEN 'VIEW' WHEN 'c' THEN 'TYPE' WHEN 'f' THEN 'FOREIGN TABLE' WHEN 'm' THEN 'MATERIALIZED VIEW' ELSE NULL END ELSE NULL END AS TABLE_TYPE, d.description AS REMARKS FROM pg_catalog.pg_namespace n, pg_catalog.pg_class c LEFT JOIN pg_catalog.pg_description d ON (c.oid = d.objoid AND d.objsubid = 0) LEFT JOIN pg_catalog.pg_class dc ON (d.classoid=dc.oid AND dc.relname='pg_class') LEFT JOIN pg_catalog.pg_namespace dn ON (dn.oid=dc.relnamespace AND dn.nspname='pg_catalog') WHERE c.relnamespace = n.oid AND c.relname LIKE 'availability_table' ORDER BY TABLE_TYPE,TABLE_SCHEM,TABLE_NAME 

je prends toutes les idées.

grâce

Answer 1

Enfin,

Je demande de modification: sélectionnez 1; par une simple "select value from singleRowTable"
=> la requête "select value from singleRowTable" est enregistrée quelques fois par Newrelic, => le travail preferredQuery.

Après avoir regardé en détail la demande, et le lien stacktrace, elle vient de org.springframework.jdbc.core.simple.SimpleJdbcInsert.

En fait, le SimpleJdbcInsert était utilisé comme prototype pour chaque insertion. Je change cela en instance dao variable et metaData était une requête par instance seulement.

Answer 2

Je ne pense pas que vous travaillez avec ce que vous pensez que vous travaillez.

c3p0-0.9.5.2 s'exécuter sur le pilote JDBC 4.1 de Postgres ne serait jamais l'ancienne requête de nom de table par défaut. Il utiliserait la méthode Connection.isValid(...) si aucun preferredTestQuery n'était défini. Je suppose que vous avez une ancienne version de c3p0 et/ou Postgres JDBC quelque part dans CLASSPATH de votre application. Notez qu'il y a une bizarrerie que vous devriez essayer de chasser dans les choses que vous avez postées. Le preferredTestQuery que vous configurez actuellement est "select 2", tandis que le preferredTestQuery de DataSource dans vos journaux est "select 1". De même, vous configurez un unreturnedConnectionTimeout sur 10, mais dans la configuration connectée, il est unset (0). Vous consignez une source de données similaire à celle que vous configurez, mais pas la même que celle-ci. Je suppose que la raison pour laquelle les choses deviennent bizarres en production est que dans votre environnement de production mais pas dans votre environnement de test, vous avez des bibliothèques plus anciennes (pilotes c3p0 et/ou postgres) et d'autres DataSources configurées pour les applications plus anciennes.

Notez que c3p0 est très stable sur sa sémantique. Il est peu probable que cela nuise à vos anciennes applications si vous effectuez une mise à niveau vers 0.9.5.2. (Juste être sûr d'inclure sa dépendance mchange-commons-java 0.2.11 ou ultérieure.)