Fechando Conexões JDBC no Conjunto

Nossa seção de código padrão para usar o JDBC é …

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(); 

Pergunta 1: Ao usar o pool de conexões, deve-se fechar a conexão no final? Em caso afirmativo, não é o propósito de agrupar perdido? E se não, como o DataSource sabe quando uma determinada instância do Connection é liberada e pode ser reutilizada? Estou um pouco confuso sobre este, qualquer pointers apreciados.

Pergunta 2: O método a seguir é algo próximo do padrão? Parece uma tentativa de obter uma conexão do pool e, se DataSource não puder ser estabelecida, use o DriverManager antigo. Nós não temos certeza de qual parte está sendo executada em tempo de execução. Repetindo a pergunta acima, deve-se fechar a conexão saindo de tal método?

Obrigado, 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); } 

Edit: Acho que estamos recebendo a conexão em pool desde que não vemos um rastreamento de pilha.

Ao usar o pool de conexões, deve-se fechar a conexão no final? Em caso afirmativo, não é o propósito de agrupar perdido? E se não, como o DataSource sabe quando uma determinada instância do Connection é liberada e pode ser reutilizada? Estou um pouco confuso sobre este, qualquer pointers apreciados.

Sim, certamente você precisa fechar a conexão em pool também. Na verdade, é um invólucro em torno da conexão real. Ele sob as cobertas libera a conexão real de volta à piscina. Além disso, cabe ao pool decidir se a conexão real será realmente fechada ou reutilizada para uma nova chamada getConnection() . Portanto, independentemente de você estar usando um pool de conexões ou não, você deve sempre fechar todos os resources do JDBC em ordem inversa no bloco finally bloco try onde os adquiriu. No Java 7, isso pode ser ainda mais simplificado usando a instrução try-with-resources .


O seguinte método é algo próximo do padrão? Parece uma tentativa de obter uma conexão do pool e, se DataSource não puder ser estabelecida, use o DriverManager antigo. Nós não temos certeza de qual parte está sendo executada em tempo de execução. Repetindo a pergunta acima, deve-se fechar a conexão saindo de tal método?

O exemplo é bem assustador. Você só precisa pesquisar / inicializar o DataSource apenas uma vez durante a boot do aplicativo em algum construtor / boot de uma class de configuração de DB em todo o aplicativo. Em seguida, apenas chame getConnection() na mesma fonte de dados durante o restante da vida útil do aplicativo. Não há necessidade de synchronization nem de nullchecks.

Veja também:

  • É seguro usar uma instância java.sql.Connection estática em um sistema multithread?
  • Estou usando o pool de conexão JDBC?

Os pools normalmente retornam um object Connection envolvido, em que o método close () é substituído, geralmente retornando a Conexão ao pool. Chamar close () é OK e provavelmente ainda é necessário.

Um método close () provavelmente seria assim:

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

Para sua segunda pergunta, você poderia adicionar um logger para mostrar se o bloco inferior já foi executado. Eu imagino que você queira apenas um caminho ou outro para a configuração de suas conexões de database. Nós usamos somente um pool para nossos accesss ao database. De qualquer forma, fechar a conexão seria muito importante para evitar vazamentos.

    Intereting Posts