Cierre de conexiones JDBC en Pool


Nuestra sección de código estándar para usar JDBC es...

Connection conn = getConnection(...);
Statement  stmt = conn.conn.createStatement (ResultSet.TYPE_SCROLL_INSENSITIVE,
                                                ResultSet.CONCUR_READ_ONLY);
ResultSet  rset = stmt.executeQuery (sqlQuery);

// do stuff with rset

rset.close(); stmt.close(); conn.close();

Pregunta 1: Cuando se usa el Grupo de conexiones, ¿se debe cerrar la conexión al final? Si es así, ¿no se pierde el propósito de la agrupación? Y si no, ¿cómo sabe la fuente de datos cuándo una instancia particular de conexión se libera y se puede reutilizar? Estoy un poco confundido en este caso, cualquier consejo apreciado.

Pregunta 2: ¿Es el siguiente método algo cercano al estándar? Parece un intento de obtener una conexión de el grupo, y si no se puede establecer el origen de datos, utilice el antiguo DriverManager. Ni siquiera estamos seguros de qué parte se está ejecutando en tiempo de ejecución. Repitiendo la pregunta anterior, ¿se debe cerrar la Conexión que sale de tal método?

Gracias, - SRA.

synchronized public Connection getConnection (boolean pooledConnection)
                                                        throws SQLException {
        if (pooledConnection) {
                if (ds == null) {
                        try {
                                Context envCtx = (Context)
                                        new InitialContext().lookup("java:comp/env");
                                ds = (DataSource) envCtx.lookup("jdbc/NamedInTomcat");
                                return ds.getConnection();
                        } catch (NamingException e) {
                                e.printStackTrace();
                }}
                return (ds == null) ? getConnection (false) : ds.getConnection();
        }
        return DriverManager.getConnection(
                "jdbc:mysql://"+ipaddy+":"+dbPort +"/" + dbName, uName, pWord);
}

Editar: Creo que estamos obteniendo la conexión agrupada ya que no vemos un seguimiento de pila.

Author: Eyal, 2011-02-09

3 answers

Al usar el grupo de conexiones, ¿se debe cerrar la conexión al final? Si es así, ¿no se pierde el propósito de la agrupación? Y si no, ¿cómo sabe la fuente de datos cuándo una instancia particular de conexión se libera y se puede reutilizar? Estoy un poco confundido en este caso, cualquier consejo apreciado.

Sí, ciertamente también necesita cerrar la conexión agrupada. En realidad es una envoltura alrededor de la conexión real. Se wil debajo de las cubiertas de la liberación de la real conexión de vuelta a la piscina. Depende más del grupo decidir si la conexión real en realidad se cerrará o se reutilizará para una nueva llamada getConnection(). Por lo tanto, independientemente de si está utilizando un grupo de conexiones o no, debe siempre cerrar todos los recursos JDBC en orden inverso en el bloque finally del bloque try donde los ha adquirido. En Java 7 esto se puede simplificar aún más mediante el uso de try-with-resources declaración.


Es el siguiendo el método ¿algo cercano al estándar? Parece un intento de obtener una conexión del grupo,y si no se puede establecer la fuente de datos, utilice el antiguo DriverManager. Ni siquiera estamos seguros de qué parte se está ejecutando en tiempo de ejecución. Repitiendo la pregunta anterior, ¿se debe cerrar la Conexión que sale de tal método?

El ejemplo es bastante aterrador. Solo necesita buscar / inicializar DataSource solo una vez durante el inicio de la aplicación en algún constructor / inicialización de una clase applicationwide DB config. A continuación, simplemente llame a getConnection() en la misma fuente de datos durante el resto de la vida útil de la aplicación. No hay necesidad de sincronización ni nullchecks.

Véase también:

 104
Author: BalusC,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2017-05-23 12:26:01

Los repositorios normalmente devuelven un objeto de conexión envuelto, donde se sobrescribe el método close (), normalmente devolviendo la conexión al repositorio. Llamar a close() está bien y probablemente aún sea necesario.

Un método close() probablemente se vería así:

public void close() throws SQLException {
  pool.returnConnection(this);
}

Para su segunda pregunta, podría agregar un registrador para mostrar si el bloque inferior se ejecuta alguna vez. Me imagino que solo querría una forma u otra para la configuración de las conexiones de su base de datos. Nosotros únicamente utilice un pool para los accesos a nuestra base de datos. De cualquier manera, cerrar la conexión sería muy importante para evitar fugas.

 21
Author: taer,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2011-02-08 21:23:15

En realidad, el mejor enfoque para la administración de conexiones es no agruparlos en ningún código en ningún lugar.

Cree una clase SQLExecutor que sea la única ubicación que abre y cierra las conexiones.

El resto de la aplicación luego bombea sentencias al ejecutor en lugar de obtener conexiones del grupo y administrarlas (o administrarlas mal) por todo el lugar.

Puede tener tantas instancias del ejecutor como desee, pero nadie debe ser escribir código que abre y cierra conexiones en su propio nombre.

Convenientemente, esto también le permite registrar todo su SQL desde un solo conjunto de código.

 0
Author: Rodney P. Barbati,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2018-10-10 22:37:54