接続は後で閉じられますが、JDBC結果セットとステートメントは別々に閉じる必要がありますか？

使用後はすべてのJDBCリソースを閉じるのがよい習慣だと言われています。しかし、次のコードがある場合、結果セットとステートメントを閉じる必要がありますか？

Connection conn = null;
PreparedStatement stmt = null;
ResultSet rs = null;
try {
    conn = // Retrieve connection
    stmt = conn.prepareStatement(// Some SQL);
    rs = stmt.executeQuery();
} catch(Exception e) {
    // Error Handling
} finally {
    try { if (rs != null) rs.close(); } catch (Exception e) {};
    try { if (stmt != null) stmt.close(); } catch (Exception e) {};
    try { if (conn != null) conn.close(); } catch (Exception e) {};
}

問題は、接続を閉じることで問題が解決するか、それとも一部のリソースが使用中のままになるかです。

あなたがしたことは完璧でとても良い習慣です。

私がその良い習慣を言う理由...たとえば、何らかの理由で「プリミティブ」タイプのデータベースプーリングを使用しているときにを呼び出したconnection.close()場合、接続はプールに返され、ResultSet/ Statementは決して閉じられないため、多くの異なる新しい問題が発生します！

したがってconnection.close()、クリーンアップに常に期待することはできません。

これが役に立てば幸いです:)

Java 1.7では、try-with-resourcesステートメントのおかげで私たちの生活がはるかに簡単になりました。

try (Connection connection = dataSource.getConnection();
    Statement statement = connection.createStatement()) {
    try (ResultSet resultSet = statement.executeQuery("some query")) {
        // Do stuff with the result set.
    }
    try (ResultSet resultSet = statement.executeQuery("some query")) {
        // Do more stuff with the second result set.
    }
}

この構文は非常に簡潔でエレガントです。そして、connection実際にしても閉じられますstatement作成することができませんでした。

以下からのJavadoc：

ときにStatementオブジェクトが閉じられ、その電流ResultSetが存在する場合、オブジェクトは、また閉じられます。

ただし、Javadocは、基礎となるを閉じるときにStatementとResultSetが閉じられるかどうかについてはあまり明確ではありませんConnection。彼らは単に接続を閉じると述べています：

このConnectionオブジェクトのデータベースとJDBCリソースが自動的に解放されるのを待つのではなく、すぐに解放します。

私の意見では、常に明示的に近いResultSets、StatementsとConnectionsあなたはの実装として、それらを終了しているとき、closeデータベースドライバの間で変化させることができます。

次のような方法を使って、自分でボイラープレートコードの多くを救うことができるcloseQuietlyでDBUtilsアパッチから。

現在、JavaでOracleを使用しています。ここに私の視点：

Oracleでは、接続を閉じた後でもカーソルを開いたままにしておくことに以前問題があったためResultSet、Statement明示的に閉じる必要があります。ResultSet（カーソル）を閉じないと、[ 開いているカーソルの最大数を超えました]などのエラーがスローされます。

使用している他のデータベースでも同じ問題が発生する可能性があります。

チュートリアルが終了したら、ResultSetを閉じます。

終了したらResultSetを閉じる

ResultSetオブジェクトを閉じるときに暗黙的にオブジェクトを閉じるResultSet場合でも、Statementオブジェクトの操作が完了するとすぐにオブジェクトを閉じ ます。クエリによってはオブジェクトが大量のメモリを占有する可能性があるためResultSet、閉じるとResultSet明示的にガベージコレクターがメモリを再収集する機会が与えResultSetられます。

ResultSet.close();

よりコンパクトなコードが必要な場合は、Apache Commons DbUtilsを使用することをお勧めします。この場合：

Connection conn = null;
PreparedStatement stmt = null;
ResultSet rs = null;
try {
    conn = // Retrieve connection
    stmt = conn.prepareStatement(// Some SQL);
    rs = stmt.executeQuery();
} catch(Exception e) {
    // Error Handling
} finally {
    DbUtils.closeQuietly(rs);
    DbUtils.closeQuietly(stmt);
    DbUtils.closeQuietly(conn);
}

JDBCに関連付けられているリソースを閉じるための正しい安全な方法（JDBCリソースを適切に閉じる方法から-毎回取得）：

Connection connection = dataSource.getConnection();
try {
    Statement statement = connection.createStatement();

    try {
        ResultSet resultSet = statement.executeQuery("some query");

        try {
            // Do stuff with the result set.
        } finally {
            resultSet.close();
        }
    } finally {
        statement.close();
    }
} finally {
    connection.close();
}

Connectionがプール可能かどうかは関係ありません。プール可能な接続でも、プールに戻る前にクリーンアップする必要があります。

「クリーン」とは通常、結果セットを閉じ、保留中のトランザクションをロールバックしますが、接続は閉じません。さもなければ、プーリングはその意味を失います。

いいえ、接続を閉じる必要はありません。JDBC仕様によると、上位のオブジェクトを閉じると、下位のオブジェクトも自動的に閉じます。を閉じるConnectionとStatement、接続が作成したがすべて閉じられます。any Statementを閉じると、ResultSetそれによって作成されたすべてのが閉じますStatement。Connectionがプール可能かどうかは関係ありません。プール可能な接続でも、プールに戻る前にクリーンアップする必要があります。

もちろん、Connectionたくさんのステートメントを作成する際に長いネストされたループがあるかもしれませんが、それらを閉じることが適切です。私はほとんど決して近いResultSetけれども、閉じるときに過度思わStatementまたはConnectionそれらを閉じます。

再利用可能なワンライナーを作成するために、次のメソッドを作成しました。

public void oneMethodToCloseThemAll(ResultSet resultSet, Statement statement, Connection connection) {
    if (resultSet != null) {
        try {
            if (!resultSet.isClosed()) {
                resultSet.close();
            }
        } catch (SQLException e) {
            e.printStackTrace();
        }
    }
    if (statement != null) {
        try {
            if (!statement.isClosed()) {
                statement.close();
            }
        } catch (SQLException e) {
            e.printStackTrace();
        }
    }

    if (connection != null) {
        try {
            if (!connection.isClosed()) {
                connection.close();
            }
        } catch (SQLException e) {
            e.printStackTrace();
        }
    }
}

このコードは、DBクエリを送信するすべてのクラスに継承される親クラスで使用します。結果セットがない場合でも、すべてのクエリでOnelinerを使用できます。メソッドは、ResultSet、Statement、Connectionを正しい順序で閉じる処理を行います。これが最終的に私のブロックがどのように見えるかです。

finally {
    oneMethodToCloseThemAll(resultSet, preStatement, sqlConnection);
}

私が覚えている限りでは、現在のJDBCでは、ResultsetsとステートメントはAutoCloseableインターフェースを実装しています。つまり、破棄されるか範囲外になると、自動的に閉じられます。

いくつかの便利な機能：

public static void silentCloseResultSets(Statement st) {
    try {
        while (!(!st.getMoreResults() && (st.getUpdateCount() == -1))) {}
    } catch (SQLException ignore) {}
}
public static void silentCloseResultSets(Statement ...statements) {
    for (Statement st: statements) silentCloseResultSets(st);
}

Java 6フォームでは、閉じる前に閉じるかどうかを確認することをお勧めします（たとえば、一部の接続プーラーが他のスレッドで接続を排除する場合）-たとえば、いくつかのネットワークの問題-ステートメントと結果セットの状態が閉じる可能性があります。（それは頻繁には起こりませんが、OracleとDBCPでこの問題がありました）。私のパターンは（古いJava構文で）そのためです：

try {
    //...   
    return resp;
} finally {
    if (rs != null && !rs.isClosed()) {
        try {
            rs.close();
        } catch (Exception e2) { 
            log.warn("Cannot close resultset: " + e2.getMessage());
        }
    }
    if (stmt != null && !stmt.isClosed()) {
        try {
            stmt.close();
        } catch (Exception e2) {
            log.warn("Cannot close statement " + e2.getMessage()); 
        }
    }
    if (con != null && !conn.isClosed()) {
        try {
            con.close();
        } catch (Exception e2) {
            log.warn("Cannot close connection: " + e2.getMessage());
        }
    }
}

理論的には、クローズ状態のチェックとクローズ自体のチェックの間に状態の変化の余地があるため、100％完全ではありません。最悪の場合、長い間警告が表示されます。-しかし、長期実行クエリで状態が変化する可能性よりも低くなります。このパターンは「アバレッジ」ロード（同時ユーザー150人）で本番環境で使用しており、問題はありませんでした。そのため、警告メッセージは表示されません。