Comparación de rendimiento de las agrupaciones de conexiones JDBC

Question

¿Alguien tiene alguna información que compare las características de rendimiento de las diferentes implementaciones de ConnectionPool?

Antecedentes: Tengo una aplicación que ejecuta actualizaciones de bases de datos en subprocesos de fondo a una instancia de mysql en el mismo cuadro. Utilizando el origen de datos com.mchange.v2.c3p0.ComboPooledDataSource nos daría SocketExceptions ocasionales: com.mysql.jdbc.CommunicationsException: fallo del enlace de comunicaciones debido a excepción subyacente:

** BEGIN NESTED EXCEPTION ** 

java.net.SocketException 
MESSAGE: Broken pipe 

STACKTRACE: 

java.net.SocketException: Broken pipe 
     at java.net.SocketOutputStream.socketWrite0(Native Method) 

El aumento del tiempo de espera de conexión de MySQL aumentó la frecuencia de estos errores

Estos errores han desaparecido al cambiar a un grupo de conexiones diferente (com.mysql.jdbc.jdbc2.optional.MysqlConnectionPoolDataSource); sin embargo, el rendimiento puede ser peor y el perfil de la memoria es notablemente menor (obtenemos menos, y mucho más grandes, GC que el conjunto de c3p0).

Answer 1

Cualquiera que sea el grupo de conexiones que utilice, debe suponer que la conexión podría cerrarse aleatoriamente en cualquier momento y hacer que su aplicación se ocupe de ello.

En el caso de una conexión de base de larga data en una red "confiable", lo que sucede a menudo es que el sistema operativo aplica un límite de tiempo para abrir las conexiones o periódicamente ejecuta un código de "limpieza de conexión". Pero la causa no importa demasiado: es solo parte de la vida de la red que se debe asumir que la conexión se puede "sacar de sus pies", y lidiar con este escenario en consecuencia.

Dado que, realmente no puedo ver el punto de un marco de grupo de conexiones que no le permite manejar este caso mediante programación.

(Dicho sea de paso, este es otro de mis casos en que me alegro de escribir mi propio código de grupo de conexiones, no hay cajas negras que comen memoria misteriosamente y no tienen que buscar el "parámetro mágico" ...)

Answer 2

Tuve este error emergente con mysql & c3p0 también - Intenté varias cosas y eventualmente lo hice desaparecer. No puedo recordar, pero lo que podría haber resuelto era la bandera autoReconnect a la

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

Answer 3

¿Usted ha intentado Apache DBCP? No sé sobre C3PO pero DBCP puede manejar conexiones inactivas de diferentes maneras:

• Puede eliminar conexiones inactivas de la piscina
• Se puede ejecutar una consulta en las conexiones inactivas después de un cierto período de inactividad

También se puede probar si una conexión es válida justo antes de dársela a la aplicación, al ejecutar una consulta sobre ella; si obtiene una excepción, descarta esa conexión e intenta con otra (o crea una nueva si puede). Mucho más robusto.

Answer 4

Es posible que desee echar un vistazo a algunos números de referencia en http://jolbox.com - el sitio que aloja BoneCP, un grupo de conexión que es más rápido que C3P0 y DBCP.

Answer 5

tubería rota

que aproximadamente significa que la otra parte ha abortado/timedout/cierra la conexión. ¿No estás manteniendo las conexiones abiertas desde hace mucho tiempo? Asegúrese de que su código esté cerrando correctamente todos los recursos JDBC (Connection, Statement y ResultSet) en el bloque finally.

Aumentando el tiempo de espera de conexión mysql aumentó la frecuencia de estos errores.

Cuide que este tiempo de espera no supere la configuración de tiempo de espera propia de la base de datos.