java - and - ¿Cómo es maxIdleTimeExcessConnections diferente de maxIdleTime en c3p0?
hibernate connection pool size (2)
Quiero configurar mi grupo de conexiones c3p0 para que al menos 2 conexiones estén siempre activas, como máximo 5, y las conexiones inactivas después de las 2 primeras caducarán en un tiempo razonable (digamos una hora).
Todo esto suena sencillo, excepto que la documentación parece implicar que no hay diferencia entre las funciones maxIdleTime y maxIdleTimeExcessConnections , lo cual me confunde.
Estados de configuración de grupo básico :
Dentro del rango entre minPoolSize y maxPoolSize, la cantidad de conexiones en un grupo varía según los patrones de uso. El número de conexiones aumenta cada vez que un usuario solicita una conexión, no hay conexiones disponibles y el grupo aún no ha alcanzado maxPoolSize en la cantidad de conexiones administradas. Como la adquisición de Connection es muy lenta, casi siempre es útil aumentar el número de conexiones con entusiasmo, en lotes, en lugar de forzar a cada cliente a esperar que una nueva conexión provoque una única adquisición cuando la carga está aumentando. acquireIncrement determina cuántas conexiones intentará adquirir un grupo c3p0 cuando el grupo se haya quedado sin conexiones. (Independientemente de acquireIncrement, la agrupación nunca permitirá que se exceda maxPoolSize).
Y el uso de minPoolSize :
Número mínimo de conexiones que un grupo mantendrá en un momento dado.
Bien, excelente. Y para configurar el tiempo de conexión:
maxIdleTimeExcessConnections se trata de minimizar la cantidad de conexiones mantenidas por las agrupaciones c3p0 cuando la agrupación no está bajo carga. De forma predeterminada, las agrupaciones c3p0 crecen bajo carga, pero solo se reducen si las conexiones fallan en una prueba de conexión o caducan a través de los parámetros descritos anteriormente. Algunos usuarios quieren que sus pools liberen conexiones innecesarias rápidamente después de un aumento en el uso que obliga a un tamaño de grupo grande. Puede lograr esto estableciendo maxIdleTimeExcessConnections en un valor mucho más corto que maxIdleTime, forzando a las conexiones más allá de su tamaño mínimo a ser liberadas si permanecen inactivas por más de un período corto de tiempo.
Por lo tanto, se da a entender que minPoolSize solo importa cuando se utiliza junto con maxIdleTimeExcessConnections ; de lo contrario, solo se ignorará por completo.
Al corroborar la documentación de maxIdleTime no se menciona a minPoolSize :
Segundos una conexión puede permanecer agrupada pero no utilizada antes de ser descartada. Cero significa que las conexiones inactivas nunca caducan.
Y maxIdleTimeExcessConnections tiene sentido:
Número de segundos que se debe permitir que las conexiones que excedan minPoolSize permanezcan inactivas en la agrupación antes de ser eliminadas. Destinado a aplicaciones que desean minimizar agresivamente el número de conexiones abiertas, reduciendo la agrupación hacia minPoolSize si, después de un pico, el nivel de carga disminuye y las conexiones adquiridas ya no son necesarias. Si se establece maxIdleTime, maxIdleTimeExcessConnections debería ser más pequeño para que el parámetro tenga algún efecto. Cero significa que no hay aplicación, el exceso de conexiones no están inactivas.
Me parece realmente extraño que minPoolSize , una característica básica, solo importe cuando se usa con lo que me parece una característica más avanzada. ¿Esto es todo correcto?
¡Qué lectura cuidadosa y leída de abogado!
pero no, no es correcto
hay varias maneras en que una Conexión puede morir. como citas:
Las agrupaciones c3p0 ... se contraen si las conexiones fallan en una prueba de conexión o caducan a través de los parámetros descritos anteriormente.
los "parámetros descritos anteriormente" incluyen maxConnectionAge , maxIdleTime y maxIdleTimeExcessConnections . Las conexiones también se pueden eliminar del grupo porque fallan las pruebas de conexión mientras están inactivas (ver idleConnectionTestPeriod ), porque fallan las pruebas de check-in o de check-out ( testConnectionOnCheckin , testConnectionOnCheckout ), o porque fallan las pruebas activadas por una excepción en el curso de uso del cliente
sin embargo, una agrupación se reduce, minPoolSize importa, porque si la agrupación se reduce por debajo de minPoolSize , las Conexiones destruidas se reemplazarán hasta que se restablezca minPoolSize .
lo que es único de maxIdleTimeExcessConnections es que su comportamiento depende directamente del tamaño del grupo en relación con minPoolSize . todos los demás parámetros y pruebas simplemente hacen lo suyo. si lo que sucede hace que el grupo minPoolSize a algo inferior a minPoolSize , entonces c3p0 automáticamente traerá el grupo de vuelta a minPoolSize . pero maxIdleTimeExcessConnections es diferente. solo tiene algún efecto cuando el grupo es mayor que minPoolSize .
como dices, maxIdleTimeExcessConnections es una función avanzada. la mayoría de los usuarios nunca lo usan y nunca lo necesitan. se agregó porque algunos usuarios querían obligar a las agrupaciones a reducirse a minPoolSize, pero hacerlo con un tiempo maxIdleTime incondicional maxIdleTime provoca un maxIdleTime innecesario a través de las conexiones, ya que las conexiones incluso en un grupo minPoolSize y se reemplazan constantemente. establecer un maxIdleTime largo o inexistente, mientras que establecer un maxIdleTimeExcessConnections corto produce el resultado deseado de reducción rápida y agresiva sin agitar a través de Connections una vez que el conjunto llega a minPoolSize .
pero incluso sin el conjunto minPoolSize , minPoolSize importa mucho. Las conexiones se destruyen y eliminan del grupo, y minPoolSize determina un umbral por debajo del cual las Conexiones destruidas se reemplazarán automáticamente, incluso si la carga del cliente no llega a provocar la expansión del grupo.
¡Espero que esto tenga sentido!
Buena respuesta de Steve Walkdman, solo quiero agregar una respuesta breve:
La diferencia es que maxIdleTime reemplazará las conexiones inactivas incluso en minPoolSize -d pools, mientras que maxIdleTimeExcessConnections no lo hará.