Primero, comprendamos las propiedades de mysql.
interactive_timeout:tiempo de espera interactivo para sesiones de shell de mysql en segundos, como mysqldump o las herramientas de línea de comandos de mysql. las conexiones están en estado de reposo. La mayoría de las veces, esto se establece en un valor más alto porque no desea que se desconecte mientras está haciendo algo en mysql cli.wait_timeout:la cantidad de segundos durante la inactividad que MySQL esperará antes de cerrar una conexión en una conexión no interactiva en segundos. ejemplo:conectado desde java. las conexiones están en estado de suspensión.
Ahora comprendamos las propiedades de c3po y su relación con los accesorios de base de datos. (Solo voy a copiar de su pregunta)
Esto se refiere a cuánto tiempo puede usarse un objeto de conexión y estará disponible en el grupo. Una vez que finaliza el tiempo de espera, c3po lo destruirá o lo reciclará.
Ahora el problema viene cuando tienes maxIdleTime más alto que el wait_timeout .digamos si el mxIdleTime : 50 segundos y wait_timeout : 40 s entonces existe la posibilidad de que obtenga Connection time out exception: Broken Pipe si intenta realizar alguna operación en los últimos 10 segundos. Entonces maxIdelTime siempre debe ser menor que wait_timeout .
En lugar de maxIdleTime, puede tener las siguientes propiedades.
idleConnectionTestPeriodestablece un límite al tiempo que una conexión permanecerá inactiva antes de probarla. SinpreferredTestQuery, el valor predeterminado esDatabaseMetaData.getTables()- que es independiente de la base de datos, y aunque es una llamada relativamente costosa, probablemente esté bien para una base de datos relativamente pequeña. Si está paranoico con respecto al rendimiento, use una consulta específica para su base de datos(i.e. preferredTestQuery="SELECT 1")maxIdleTimeExcessConnectionsdevolverá el recuento de conexiones a minPoolSize después de un pico en la actividad.
Tenga en cuenta que cualquiera de las propiedades del grupo (p. ej., maxIdleTime ) solo afecta a la conexión que está en el grupo es decir, si hibernate ha adquirido una conexión y la mantiene inactiva durante maxIdleTime y luego intenta realizar cualquier operación, obtendrá "Broken Pipe"
Es bueno tener menos wait_timeout en mysql pero no siempre es correcto cuando ya tiene una aplicación construida. Debe asegurarse antes de reducirla de que en su aplicación no mantiene la conexión abierta por más de wait_time fuera.
También debe tener en cuenta que adquirir una conexión es una tarea costosa y si el tiempo de espera es demasiado bajo, supera el propósito de tener un grupo de conexiones, ya que con frecuencia intentará adquirir conexiones.
Esto es especialmente importante cuando no realiza la administración de la conexión de forma manual, por ejemplo, cuando utiliza la API transnacional de Spring. Spring inicia la transacción cuando ingresa un @Transaction método anotado para que adquiera una conexión del grupo. Si está realizando una llamada de servicio web o leyendo algún archivo que llevará más tiempo que el tiempo de espera, obtendrá una excepción.
Me he enfrentado a este problema una vez.
En uno de mis proyectos, tenía un cron que procesaba los pedidos de los clientes. Para hacerlo más rápido, utilicé el procesamiento por lotes. Ahora, una vez que recupero un lote de clientes y realizo un procesamiento (sin llamadas a db). Cuando trato de guardar todos los pedidos, solía obtener una excepción de tubería rota. El problema era que mi espera_tiempo de espera era de 1 minuto y el procesamiento de pedidos tomaba más tiempo que eso. Así que tuvimos que aumentarlo a 2 minutos. Podría haber reducido el tamaño del lote, pero eso estaba haciendo que el procesamiento general fuera más lento.
