Cierre de las conexiones JDBC en el grupo

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 utiliza el grupo de conexiones, ¿se debe cerrar la conexión al final? Si es así, ¿no es el propósito de agrupar perdido? Y si no, ¿cómo sabe DataSource cuando se libera una instancia particular de Connection y se puede reutilizar? Estoy un poco confundido con esto, cualquier sugerencia apreciada.

Pregunta 2: ¿El siguiente método es cercano al estándar? Parece un bash de obtener una conexión del grupo, y si DataSource no se puede establecer, utilice el DriverManager anterior. Ni siquiera estamos seguros de qué parte se ejecutará en tiempo de ejecución. Repitiendo la pregunta anterior, ¿debería uno cerrar la conexión que sale de tal método?

Gracias, – MS.

 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 mancomunada ya que no vemos un rastro de stack.

Al usar Connection Pool, ¿debería uno cerrar la conexión al final? Si es así, ¿no es el propósito de agrupar perdido? Y si no, ¿cómo sabe DataSource cuando se libera una instancia particular de Connection y se puede reutilizar? Estoy un poco confundido con esto, cualquier sugerencia apreciada.

Sí, ciertamente también debe cerrar la conexión agrupada. En realidad es un envoltorio alrededor de la conexión real. Debajo de las cubiertas liberará la conexión real de vuelta a la piscina. Depende de la agrupación decidir si la conexión real se cerrará o si se reutilizará para una nueva llamada a getConnection() . Entonces, independientemente de si está utilizando un grupo de conexiones o no, siempre debe cerrar todos los recursos JDBC en orden inverso en el bloque finally bloque try donde los haya adquirido. En Java 7 esto se puede simplificar aún más mediante el uso try-with-resources statement try-with-resources .


¿El siguiente método es cercano al estándar? Parece un bash de obtener una conexión del grupo, y si DataSource no se puede establecer, utilice el DriverManager anterior. Ni siquiera estamos seguros de qué parte se ejecutará en tiempo de ejecución. Repitiendo la pregunta anterior, ¿debería uno cerrar la conexión que sale de tal método?

El ejemplo es bastante aterrador. Solo necesita buscar / inicializar el DataSource solo una vez durante el inicio de la aplicación en algún constructor / inicialización de una clase de configuración DB de toda la aplicación. A continuación, simplemente llame a getConnection() en el mismo origen de datos durante el rest de la vida útil de la aplicación. Sin necesidad de sincronización ni nullchecks.

Ver también:

  • ¿Es seguro usar una instancia java.sql.Connection estática en un sistema multiproceso?
  • ¿Estoy utilizando la agrupación de conexiones JDBC?

Las agrupaciones generalmente le devuelven un objeto de conexión empaquetado, donde el método close () se reemplaza, normalmente devolviendo la conexión al grupo. Llamar close () está bien y probablemente todavía se requiera.

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 alguna vez se ejecuta el bloque de abajo. Me imagino que solo querrá de una forma u otra la configuración de las conexiones de su base de datos. Solo utilizamos un grupo para nuestros accesos a la base de datos. De cualquier manera, cerrar la conexión sería muy importante para evitar fugas.