java - servidor - Problema fundamental en la agrupación de conexiones de Tomcat

servidor tomcat

Question

Estoy utilizando la agrupación de conexiones de Tomcat 7 (como un recurso de Tomcat en server.xml y context.xml) en una aplicación web y funciona.
Mi pregunta es: ¿es posible "decirle" / "forzar" a Tomcat a disponer del conjunto de conexiones una vez creado?

La razón por la que pregunto es la siguiente:
Estoy usando H2 y me encuentro con un problema de "carrera" al apagar.
H2 permanece abierto mientras haya una conexión abierta, pero Tomcat no dispone del conjunto de conexiones, por lo que las conexiones permanecen abiertas. Y como resultado tengo varios problemas en el cierre.

Descubrí que podía emitir un comando SQL SHUTDOWN para cerrar H2 pero quería explorar todas las alternativas para mi caso.

Entonces, ¿es posible "decirle" / "forzar" a Tomcat a disponer del conjunto de conexiones (al menos al apagarlo)?

Answer 1

Creo que puedes tratar de poner el registro de depuración y verificar si su problema con la conexión no es liberado por la aplicación o por algún otro parámetro de configuración de fuente de datos en server.xml.

sobre todo, debería ser el caso donde la aplicación no está liberando la conexión.

Answer 2

Como se describe en la documentación http://tomcat.apache.org/tomcat-7.0-doc/config/context.html#Resource_Definitions, es posible establecer closeMethod of container datasource. No estoy seguro de ''eliminar'' el grupo de conexiones, pero creo que vale la pena intentarlo.

Nombre del método de argumento cero para invocar un recurso singleton cuando ya no es necesario. Esto tiene la intención de acelerar la limpieza de los recursos que de otro modo pasarían como parte de la recolección de basura. Este atributo se ignora si el atributo singleton es falso. Si no se especifica, no se define ningún valor predeterminado y no se llamará a ningún método de cierre.

También puede implementar DataSource programáticamente y comenzar / detenerlo en ServletContextListener , ejemplo para dbcp (lo siento de mi unidad de pruebas, pero fácil de reescribir):

import org.apache.commons.dbcp.BasicDataSource;

static BasicDataSource bds = new BasicDataSource();

@BeforeClass
public void setUp() throws Exception {
    bds.setDefaultAutoCommit(false);
    bds.setDriverClassName("org.h2.Driver");
    bds.setInitialSize(0);
    bds.setMaxActive(2);
    bds.setMaxWait(10000);
    bds.setPassword(null);
    bds.setUrl("jdbc:h2:mem:test;DB_CLOSE_DELAY=-1");
    bds.setUsername("sa");
    bds.setValidationQuery("select 1 as test");
}

@AfterClass
public void tearDown() throws Exception {
    bds.close();
}

Answer 3

Tal vez no entiendo la pregunta. Para ser más claros, si cierras Tomcat (y por lo tanto es JVM), entonces ni Tomcat ni sus pools de conexión, ni ninguno de sus hilos daemon seguirían vivos ... y por lo tanto, no quedarían referencias en memoria.

¿Cómo exactamente ha llegado a la conclusión de que un recurso Tomcat tiene una referencia a un grupo de conexiones, después de que se cierre Tomcat? No sería capaz de ver eso en un generador de perfiles y, francamente, no tiene mucho sentido. Por ejemplo, ¿es posible que el sistema operativo mantenga las conexiones abiertas durante un corto período de tiempo antes de destruirlas? ¿Has probado las mismas pruebas utilizando el mismo sistema operativo, pero en cambio con un contenedor diferente, algo así como Jetty? ¿Estás usando Keep-Alives o alguna forma de conexión persistente?

Si quiere ensuciarse con la administración de Tomcat de un recurso expuesto a través de JNDI, puede hacer su propia implementación de DataSource que delegue en H2 DataSource. Puedes hacer esto usando el atributo factory-method en tu server.xml (o context.xml)

Aquí hay un ejemplo de trabajo en github: https://github.com/tvollmer/connection-factory

Más allá de eso, sería útil si pudieras aclarar aún más a qué te refieres con "varios problemas de cierre". Esos detalles importan, y no me queda claro cómo ha pasado lógicamente de "varios problemas" a decir que Tomcat "no dispone del conjunto de conexiones". Podría tratar con 2 problemas completamente separados aquí, y es posible que desee verificar las configuraciones antiResourceLocking y antiJARLocking para Tomcat en Windows.

Answer 4

¿Qué le parece escribir un ServletContextListener personalizado y luego cerrar el grupo cuando se destruye el contexto? Aquí hay un artículo sobre ServletContextListener que se utiliza para crear ganchos de cierre:

cerrar el enlace para la aplicación web java

La API para los oyentes de contexto parece bastante sencilla:

http://docs.oracle.com/javaee/5/api/javax/servlet/ServletContextListener.html

Answer 5

por favor vea mi respuesta en: Problema de parámetros JNDI específicos del contexto en tomcat 6 . Hay muchas cosas que puedes hacer con el recurso jndi.

<Resource name="jdbc/NAME" auth="Container" type="javax.sql.DataSource"
               maxActive="100" minIdle="10" maxWait="10000" removeAbandoned="true"
               removeAbandonedTimeout="60" logAbandoned="true"
               testWhileIdle="true" testOnBorrow="true" testOnReturn="false"
               timeBetweenEvictionRunsMillis="5000"
               validationQuery="SELECT 1" initialSize="10"
               username="usrname" password="password"   
               driverClassName="com.mysql.jdbc.Driver"
               url="jdbc:mysql://localhost:3306/databb?autoReconnect=true"/>