java - descargar - La conexión con MySql se cancela automáticamente. ¿Cómo configurar Connector/J correctamente?

mysql connector java 8.0 11 jar

Question

Leí este consejo del mensaje de error:

Debe considerar caducar y / o probar la validez de la conexión antes de usarla en su aplicación, aumentar los valores configurados del servidor para los tiempos de espera del cliente o usar la propiedad de conexión del Conector / J ''autoReconnect = true'' para evitar este problema.

Estoy usando Spring y JPA. ¿Dónde debo configurar Connector / J? (en persistence.xml , o en la configuración del resorte de entityManagerFactory , o en la configuración del resorte dateSource , o en otro lugar?)

Answer 1

El texto describe tres soluciones para evitar abortos de conexión:

1. Configure la cadena de conexión con autoReconnect=true . Esta es una propiedad de la cadena de conexión URL, que funciona en el nivel del controlador. Necesita cambiar la cadena de conexión en la configuración del origen de datos.

   url="jdbc:mysql://localhost:3306/confluence?autoReconnect=true"

2. Aumenta el tiempo de espera. Esto es normalmente una propiedad de la base de datos. Puede aumentar este valor para ver si obtiene menos aborto de conexión.

3. Configure el grupo de conexiones para probar la validación de la conexión. Esto se hace en el grupo, no en el nivel del controlador. Esto dependerá de la implementación de la fuente de datos que use. Pero debe ser configurable en la propiedad de la fuente de datos, si usa uno agrupado, por ejemplo, c3p0 .

   • Opciones de agrupación de conexiones con JDBC: DBCP vs C3P0
   • http://snipplr.com/view/14725/c3p0-datasource-config-connectionpool/
   • http://www.mchange.com/projects/c3p0/index.html#configuring_connection_testing

Comentarios adicionales:

• El origen de datos / grupo también puede tener un tiempo de espera, que corresponde al tiempo que una conexión inactiva permanece en el grupo. Para no confundir con el tiempo de espera de db.
• Hay varias formas de probar la validez de una conexión. Una forma común es tener una tabla de prueba ficticia. El grupo emitirá una selección en la tabla de prueba ficticia para ver si la conexión sigue siendo correcta.

Answer 2

Esto es para personas como yo que encuentran esta publicación antigua a través de los motores de búsqueda.

Las otras respuestas son mejores soluciones a largo plazo . Pero si solo necesita que la conexión mysql vuelva a funcionar de inmediato, puede shutdown y restart tomcat y todo funcionará bien por un tiempo. Esto le permite evitar el tiempo de inactividad del sistema mientras calcula una solución a más largo plazo.

Navegue hasta $CATALINA_HOME en la terminal , luego escriba shutdown.sh , luego escriba startup.sh . Espere unos minutos para que se complete la secuencia de inicio, luego sus aplicaciones funcionarán nuevamente por un tiempo.

Answer 3

Pasé por muchas soluciones y mi problema fue resuelto, pero después de un tiempo la conexión se agotó o se desconectó. Después de 2 3 días, obtuve una solución que solucionaba mi problema.

muchas soluciones sugieren usar autoReconnect = true pero cuando fui a través de los documentos. Vi el siguiente texto en la fuente que describe el parámetro autoReconnect:

No se recomienda el uso de esta función, ya que tiene efectos secundarios relacionados con el estado de la sesión y la coherencia de los datos.

Cuando miré en el código de Hibernate. El mecanismo de conexión básico de Hibernate no es compatible con la reconexión, uno tiene que usar el conjunto de conexiones H3C0 (que a su vez no siempre admite la reconexión).

Pero una vez que uno usa H3C0, el comportamiento predeterminado parece ser que para procesar una solicitud, si la conexión está muerta, el usuario ve y produce un error, pero al menos se vuelve a conectar para la siguiente solicitud. Supongo que un error es mejor que los errores infinitos, pero aún no es tan bueno como cero errores. Resulta que se necesita la opcióntestConnectionOnCheckout, que la documentación no recomienda, ya que probar la conexión antes de una solicitud puede dar lugar a un menor rendimiento. Seguramente el software primero tiene que funcionar, solo que en segundo lugar tiene que funcionar rápido.

Por lo tanto, para resumir, para obtener una conexión a "trabajo" (que defino que incluye el manejo de conexiones caídas volviendo a conectar sin error): en "hibernate.cfg.xml":

  <!-- hibernate.cfg.xml -->
    <property name="c3p0.min_size">5</property>
    <property name="c3p0.max_size">20</property>
    <property name="c3p0.timeout">1800</property>
    <property name="c3p0.max_statements">50</property>
    <!-- no "connection.pool_size" entry! -->

A continuación, cree un archivo "c3p0.properties" que debe estar en la raíz de la ruta de clases (es decir, no hay manera de anularlo para partes particulares de la aplicación):

c3p0.properties

c3p0.testConnectionOnCheckout = true

Si esta solución no funciona, hay más soluciones posibles:

1. Add

<property name="connection.provider_class">org.hibernate.connection.C3P0ConnectionProvider</property>

 Also dont forget to place the c3p0-0.9.1.jar in the classpath. 



    2. Instead of using that c3p0.properties file, couldn''t you just use this property in your hibernate.cfg.xml:

<property name="hibernate.c3p0.validate">true</property>

    Also checkout the last post on this page:

    https://forum.hibernate.org/viewtopic.php?p=2399313

    If all these not work than go [more][1] and read in detail


  [1]: http://hibernatedb.blogspot.in/2009/05/automatic-reconnect-from-hibernate-to.html

Answer 4

AutoReconnect no es recomendado. De MySQL here

¿Debería el conductor tratar de restablecer conexiones obsoletas y / o muertas? Si está habilitado, el controlador emitirá una excepción para las consultas emitidas en una conexión obsoleta o muerta, que pertenecen a la transacción actual, pero intentará reconectarse antes de la próxima consulta emitida en la conexión en una nueva transacción. No se recomienda el uso de esta función, ya que tiene efectos secundarios relacionados con el estado de la sesión y la coherencia de los datos cuando las aplicaciones no manejan SQLExceptions correctamente, y solo está diseñado para ser utilizado cuando no puede configurar su aplicación para manejar SQLExceptions resultante de conexiones muertas y viejas a tiempo. Alternativamente, como última opción, investigue la configuración de la variable del servidor MySQL "wait_timeout" en un valor alto, en lugar del valor predeterminado de 8 horas.