Các kết quả và báo cáo JDBC phải được đóng riêng mặc dù Kết nối được đóng lại sau đó?

Nó được cho là một thói quen tốt để đóng tất cả các tài nguyên JDBC sau khi sử dụng. Nhưng nếu tôi có đoạn mã sau, có cần thiết phải đóng Kết quả và Tuyên bố không?

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) {};
}

Câu hỏi là nếu việc đóng kết nối thực hiện công việc hoặc nếu nó để lại một số tài nguyên được sử dụng.

Những gì bạn đã làm là hoàn hảo và thực hành rất tốt.

Lý do tôi nói rằng thông lệ tốt của nó ... Ví dụ: nếu vì lý do nào đó bạn đang sử dụng loại cơ sở dữ liệu "nguyên thủy" và bạn gọi connection.close(), kết nối sẽ được trả về nhóm và ResultSet/ Statementsẽ không bao giờ bị đóng và sau đó bạn sẽ gặp nhiều vấn đề mới khác nhau!

Vì vậy, bạn không thể luôn luôn trông chờ vào connection.close()việc dọn dẹp.

Tôi hi vọng cái này giúp được :)

Java 1.7 làm cho cuộc sống của chúng ta dễ dàng hơn nhiều nhờ vào câu lệnh try-with-resource .

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.
    }
}

Cú pháp này khá ngắn gọn và thanh lịch. Và connectionthực sự sẽ bị đóng cửa ngay cả khi statementkhông thể được tạo ra.

Từ javadocs :

Khi một Statementđối tượng được đóng lại, ResultSetđối tượng hiện tại của nó , nếu một đối tượng tồn tại, cũng bị đóng lại.

Tuy nhiên, javadocs không rõ lắm về việc có Statementvà ResultSetđược đóng khi bạn đóng bên dưới không Connection. Họ chỉ đơn giản nói rằng đóng một kết nối:

Phát hành Connectioncơ sở dữ liệu và tài nguyên JDBC của đối tượng này ngay lập tức thay vì chờ chúng được tự động phát hành.

Theo tôi, lúc nào cũng rõ ràng chặt chẽ ResultSets, Statementsvà Connectionskhi bạn đã kết thúc với họ như việc thực hiện closecó thể khác nhau giữa các trình điều khiển cơ sở dữ liệu.

Bạn có thể tiết kiệm cho mình rất nhiều mã nồi hơi bằng cách sử dụng các phương thức như closeQuietlytrong DBUtils từ Apache.

Tôi hiện đang sử dụng Oracle với Java. Đây là quan điểm của tôi:

Bạn nên đóng ResultSetvà Statementrõ ràng bởi vì Oracle có vấn đề trước đây với việc giữ các con trỏ mở ngay cả sau khi đóng kết nối. Nếu bạn không đóng ResultSet(con trỏ), nó sẽ gây ra lỗi như vượt quá con trỏ mở tối đa .

Tôi nghĩ bạn có thể gặp phải vấn đề tương tự với các cơ sở dữ liệu khác mà bạn sử dụng.

Dưới đây là hướng dẫn Đóng Kết quả khi hoàn thành :

Đóng Kết quả khi hoàn tất

Đóng ResultSetđối tượng ngay khi bạn kết thúc làm việc với ResultSetđối tượng mặc dù Statementđối tượng đóng ResultSethoàn toàn đối tượng khi nó đóng, đóng ResultSetrõ ràng tạo cơ hội cho trình thu gom rác để nhớ lại bộ nhớ càng sớm càng tốt vì ResultSetđối tượng có thể chiếm nhiều bộ nhớ tùy theo truy vấn.

ResultSet.close();

Nếu bạn muốn mã nhỏ gọn hơn, tôi khuyên bạn nên sử dụng Apache Commons DbUtils . Trong trường hợp này:

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

Phương thức chính xác và an toàn để đóng các tài nguyên được liên kết với JDBC này (được lấy từ Cách đóng tài nguyên JDBC đúng cách - Mọi lúc ):

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

Không quan trọng nếu Connectioncó thể poolable hay không. Ngay cả kết nối poolable cũng phải làm sạch trước khi quay trở lại pool.

"Sạch" thường có nghĩa là đóng kết quả và khôi phục mọi giao dịch đang chờ xử lý nhưng không đóng kết nối. Nếu không thì gộp lại mất ý nghĩa của nó.

Không, bạn không cần phải đóng bất cứ thứ gì NHƯNG kết nối. Mỗi thông số kỹ thuật JDBC đóng bất kỳ đối tượng cao hơn sẽ tự động đóng các đối tượng thấp hơn. Đóng Connectionsẽ đóng bất kỳ Statements mà kết nối đã tạo. Đóng bất kỳ Statementsẽ đóng tất cả các ResultSets được tạo bởi đó Statement. Không quan trọng nếu Connectioncó thể poolable hay không. Ngay cả kết nối poolable cũng phải làm sạch trước khi quay trở lại pool.

Tất nhiên bạn có thể có các vòng lặp lồng nhau dài trên việc Connectiontạo ra nhiều câu lệnh, sau đó đóng chúng là thích hợp. Tôi gần như không bao giờ đóng ResultSet, mặc dù có vẻ quá mức khi đóng Statementhoặc ConnectionSILL đóng chúng.

Tôi đã tạo Phương thức sau để tạo One liner có thể sử dụng lại:

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

Tôi sử dụng Mã này trong Lớp cha được kế thừa cho tất cả các lớp của tôi gửi Truy vấn DB. Tôi có thể sử dụng Oneliner trên tất cả các Truy vấn, ngay cả khi tôi không có kết quả. Phương thức này đảm nhiệm việc đóng Kết quả, Tuyên bố, Kết nối theo đúng thứ tự. Đây là những gì cuối cùng khối của tôi trông như thế.

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

Theo như tôi nhớ, trong JDBC hiện tại, các kết quả và câu lệnh triển khai giao diện AutoClosizable. Điều đó có nghĩa là chúng được đóng tự động khi bị phá hủy hoặc đi ra khỏi phạm vi.

Một số chức năng tiện lợi:

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

Với dạng Java 6 tôi nghĩ tốt hơn là kiểm tra xem nó có bị đóng hay không trước khi đóng (ví dụ nếu một số pooler kết nối đuổi kết nối trong luồng khác) - ví dụ như một số vấn đề về mạng - trạng thái câu lệnh và kết quả có thể bị đóng. (điều này không thường xuyên xảy ra, nhưng tôi đã gặp vấn đề này với Oracle và DBCP). Mẫu của tôi dành cho điều đó (theo cú pháp Java cũ hơn) là:

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

Về lý thuyết, nó không hoàn hảo 100% bởi vì giữa việc kiểm tra trạng thái đóng và chính nó có một khoảng trống nhỏ để thay đổi trạng thái. Trong trường hợp xấu nhất bạn sẽ nhận được một cảnh báo trong thời gian dài. - nhưng nó ít hơn khả năng thay đổi trạng thái trong các truy vấn dài hạn. Chúng tôi đang sử dụng mô hình này trong sản xuất với tải "avarage" (150 người dùng tương tự) và chúng tôi không gặp vấn đề gì với nó - vì vậy không bao giờ thấy thông báo cảnh báo đó.