Comparación de rendimiento de agrupaciones de conexiones JDBC

Question

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

Fondo: tengo una aplicación que ejecuta actualizaciones de db en subprocesos de fondo a una instancia de mysql en el mismo cuadro. El uso de Datasource com.mchange.v2.c3p0.ComboPooledDataSource nos daría SocketExceptions ocasionales:     com.mysql.jdbc.CommunicationsException: error en el enlace de comunicaciones debido a una 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 la conexión 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 memoria es notable (obtenemos menos GC, y mucho más grandes, que el grupo c3p0).

Answer 1

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

En el caso de una conexión DB de larga data en un " confiable " red, lo que sucede a menudo es que el sistema operativo aplica un límite de tiempo a cuánto tiempo pueden abrirse las conexiones, o ejecuta periódicamente alguna "limpieza de conexión". código. Pero la causa no importa demasiado: es solo parte de la vida de la red que debes asumir que la conexión se puede "quitar de debajo de tus pies" y tratar este escenario en consecuencia.

Entonces, dado eso, realmente no puedo ver el punto de un marco de agrupación de conexiones que no le permite manejar este caso mediante programación.

(Por cierto, este es otro de mis casos en los que me alegra haber escrito mi propio código de grupo de conexiones; no hay cajas negras que coman misteriosamente la memoria, y no tener que buscar para encontrar el "parámetro mágico" ... )

Answer 2

Es posible que desee ver algunos números de referencia en http://jolbox.com - el sitio Hospedaje de BoneCP, un grupo de conexiones que es más rápido que C3P0 y DBCP.

Answer 3

Tuve este error emergente con mysql & amp; c3p0 también: probé varias cosas y finalmente lo hice desaparecer. No puedo recordar, pero lo que podría haber resuelto fue la bandera de reconexión automática a la

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

Answer 4

¿Has probado Apache DBCP ? No sé acerca de c3po, pero DBCP puede manejar conexiones inactivas de diferentes maneras:

• Puede eliminar conexiones inactivas del grupo
• Puede ejecutar una consulta en conexiones inactivas después de un cierto período de inactividad

También puede probar si una conexión es válida justo antes de proporcionarla a la aplicación, ejecutando una consulta en 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 5

  

Tubo roto

Eso significa aproximadamente que el otro lado ha abortado / agotado / cerrado la conexión. ¿No mantienes conexiones tan abiertas? Asegúrese de que su código cierre correctamente todos los recursos JDBC ( Connection , Statement y ResultSet ) en el bloque finalmente.

  

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

Tenga cuidado de que este tiempo de espera no exceda la configuración de tiempo de espera del DB.