tutorial example java mysql jdbc apache-commons-dbcp

java - tutorial - tomcat 8.5 jndi datasource example



Configuración de Tomcat utilizando DBCP (2)

Dado que DBCP mantiene abiertas las conexiones mysql para las próximas solicitudes de conexión, son víctimas del tiempo de espera del servidor MySQL .

DBCP tiene una serie de características que pueden ayudar (se puede utilizar comenzando con Tomcat 5.5 IIRC).

validationQuery="SELECT 1" testOnBorrow="true"

La validación asegura que una conexión sea válida antes de devolverla a una aplicación web que ejecuta el método ''borrow''. La bandera, por supuesto, habilita esta característica.

Si el tiempo de espera (8 horas, creo) ha transcurrido y la conexión está muerta, se prueba una nueva conexión (si ya no hay ninguna, se crea) y se proporciona a la aplicación web.

Otros posibles enfoques:

  1. utilice el testWhileIdle="true" en la configuración de recursos para verificar también las conexiones inactivas antes de que se detecte una solicitud efectiva.

  2. Utilice las '' autoReconnect/autoReconnectForPools=true conexión'' para reforzar su conexión MySQL (por ejemplo, autoReconnect/autoReconnectForPools=true )

Estamos recibiendo una CommunicationsException (de DBCP) después de la identificación por un tiempo (unas pocas horas). El mensaje de error (en la Excepción) se encuentra al final de esta pregunta, pero no veo wait_timeout definido en ninguno de los archivos de configuración. (¿Dónde deberíamos buscar? ¿En algún lugar fuera del directorio tomcat / conf?).

En segundo lugar, como lo sugiere la Excepción, ¿dónde se pone "Propiedad de conexión de conector / J ''autoReconnect = true''"? Aquí está la definición de recurso en el archivo conf / context.xml en la configuración de tomcat:

<Resource name="jdbc/TomcatResourceName" auth="Container" type="javax.sql.DataSource" maxActive="100" maxIdle="30" maxWait="10000" removeAbandoned="true" removeAbandonedTimeout="60" logAbandoned="true" username="xxxx" password="yyyy" driverClassName="com.mysql.jdbc.Driver" url="jdbc:mysql://127.0.0.1:3306/dbname?autoReconnect=true"/>

En tercer lugar, ¿por qué la JVM espera hasta la llamada a executeQuery () para lanzar la excepción? Si la conexión ha excedido el tiempo de espera, el método getConnection arrojará la excepción, ¿no es así? Esta es la sección del código fuente del que estoy hablando:

try { conn = getConnection (true); stmt = conn.createStatement (ResultSet.TYPE_SCROLL_INSENSITIVE, ResultSet.CONCUR_READ_ONLY); rset = stmt.executeQuery (bQuery); while (rset.next()) { ....

Finalmente, aquí están las primeras líneas del trazado de pila ...

com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: The last packet successfully received from the server was 84,160,724 milliseconds ago. The last packet sent successfully to the server was 84,160,848 milliseconds ago. is longer than the server configured value of ''wait_timeout''. You should consider either expiring and/or testing connection validity before use in your application, increasing the server configured values for client timeouts, or using the Connector/J connection property ''autoReconnect=true'' to avoid this problem. at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) at java.lang.reflect.Constructor.newInstance(Constructor.java:532) at com.mysql.jdbc.Util.handleNewInstance(Util.java:406) at com.mysql.jdbc.SQLError.createCommunicationsException(SQLError.java:1074) at com.mysql.jdbc.MysqlIO.send(MysqlIO.java:3291) at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:1938) at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2107) at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2642) at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2571) at com.mysql.jdbc.StatementImpl.executeQuery(StatementImpl.java:1451) at org.apache.tomcat.dbcp.dbcp.DelegatingStatement.executeQuery(DelegatingStatement.java:208)

Estas son las razones por las que algunos de nosotros pensamos "olvídate de dbcp, puede ser tan dependiente de las configuraciones IDE y de la magia debajo del capó que DriverManager.getConnection (...) puede ser más confiable". ¿Algún comentario sobre eso? Gracias por tu conocimiento, - MS