Czy zestawy wyników i instrukcje JDBC muszą być zamykane osobno, mimo że połączenie jest później zamykane?

Uważa się, że dobrym nawykiem jest zamykanie wszystkich zasobów JDBC po użyciu. Ale jeśli mam następujący kod, czy konieczne jest zamknięcie zestawu wyników i instrukcji?

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

Pytanie brzmi, czy zamknięcie połączenia wykonuje zadanie, czy też pozostawia niektóre zasoby w użyciu.

To, co zrobiłeś, to doskonała i bardzo dobra praktyka.

Powodem, dla którego mówię, że jest to dobra praktyka ... Na przykład, jeśli z jakiegoś powodu używasz „prymitywnego” typu puli bazy danych i wywołujesz połączenie connection.close(), połączenie zostanie zwrócone do puli i ResultSet/ Statementnigdy nie zostanie zamknięte, a następnie napotka wiele różnych nowych problemów!

Więc nie zawsze możesz liczyć na connection.close()sprzątanie.

Mam nadzieję, że to pomoże :)

Java 1.7 znacznie ułatwia nam życie dzięki instrukcji 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.
    }
}

Ta składnia jest dość krótka i elegancka. I connectionrzeczywiście będzie zamknięty, nawet jeśli statementnie da się go stworzyć.

Z javadocs :

Kiedy Statementobiekt jest zamknięty, jego bieżący ResultSetobiekt, jeśli taki istnieje, również jest zamknięty.

Jednak javadocs nie są bardzo jasne, czy Statementi ResultSetsą zamykane po zamknięciu instrumentu bazowego Connection. Po prostu stwierdzają, że zamknięcie połączenia:

Zwalnia Connectionbazę danych tego obiektu i zasoby JDBC natychmiast, zamiast czekać na automatyczne zwolnienie.

Moim zdaniem, zawsze jawnie zamknij ResultSets, Statementsa Connectionskiedy skończysz z nimi, ponieważ implementacja closemoże się różnić w zależności od sterowników bazy danych.

Możesz zaoszczędzić sobie dużo kodu płyty kotłowej, stosując metody takie jak closeQuietlyw DBUtils firmy Apache.

Teraz używam Oracle z Javą. Oto mój punkt widzenia:

Powinieneś zamknąć ResultSeti Statementwyraźnie, ponieważ Oracle ma problemy z utrzymaniem otwartych kursorów nawet po zamknięciu połączenia. Jeśli nie zamkniesz ResultSet(kursora), pojawi się błąd, taki jak przekroczenie maksymalnej liczby otwartych kursorów .

Myślę, że możesz napotkać ten sam problem z innymi bazami danych, z których korzystasz.

Oto samouczek Zamknij zestaw wyników po zakończeniu :

Zamknij zestaw wyników po zakończeniu

Zamknij ResultSetobiekt, jak tylko skończysz pracę z ResultSetobiektem, mimo że Statementobiekt ResultSetniejawnie zamyka obiekt po zamknięciu, ResultSetjawne zamknięcie daje modułowi odśmiecającemu możliwość jak najszybszego odzyskania pamięci, ponieważ ResultSetobiekt może zajmować dużo pamięci w zależności od zapytania.

ResultSet.close();

Jeśli chcesz mieć bardziej zwarty kod, sugeruję użycie Apache Commons DbUtils . W tym przypadku:

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

Ta poprawna i bezpieczna metoda zamknięcia zasobów powiązanych z JDBC to (zaczerpnięta z Jak poprawnie zamknąć zasoby JDBC - za każdym razem ):

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

Nie ma znaczenia, czy Connectionmożna je gromadzić czy nie. Nawet połączenie z pulą musi zostać wyczyszczone przed powrotem do basenu.

„Wyczyść” zwykle oznacza zamknięcie zestawów wyników i wycofanie wszelkich oczekujących transakcji, ale nie zamknięcie połączenia. W przeciwnym razie pula traci sens.

Nie, nie musisz niczego zamykać, ALE połączenie. Zgodnie ze specyfikacją JDBC zamknięcie dowolnego wyższego obiektu spowoduje automatyczne zamknięcie niższych obiektów. Zamknięcie Connectionspowoduje zamknięcie wszystkich Statementutworzonych połączeń. Zamknięcie dowolnego Statementspowoduje zamknięcie wszystkich, ResultSetktóre zostały utworzone przez to Statement. Nie ma znaczenia, czy Connectionmożna je gromadzić czy nie. Nawet połączenie z pulą musi zostać wyczyszczone przed powrotem do basenu.

Oczywiście możesz mieć długie zagnieżdżone pętle na Connectiontworzeniu wielu instrukcji, a następnie zamknięcie ich jest właściwe. Prawie nigdy nie zamykam ResultSet, wydaje się przesadny podczas zamykania Statementlub ConnectionBĘDZIE je zamykać.

Stworzyłem następującą metodę tworzenia One Liner wielokrotnego użytku:

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

Używam tego kodu w klasie nadrzędnej odziedziczonej po wszystkich moich klasach, które wysyłają zapytania DB. Mogę używać Oneliner na wszystkich zapytaniach, nawet jeśli nie mam wynikowego zestawu. Metoda zajmuje się zamykaniem zestawu wyników, instrukcji, połączenia we właściwej kolejności. Tak wygląda mój wreszcie blok.

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

O ile pamiętam, w obecnym JDBC zestawy wyników i instrukcje implementują interfejs AutoCloseable. Oznacza to, że są one zamykane automatycznie po ich zniszczeniu lub przekroczeniu zakresu.

Niektóre funkcje wygody:

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

W przypadku formularza Java 6 lepiej jest sprawdzić, czy jest zamknięty, czy nie przed zamknięciem (na przykład, jeśli jakiś puli połączeń wyklucza połączenie w innym wątku) - na przykład jakiś problem z siecią - stan instrukcji i zestawu wyników można zamknąć. (nie zdarza się to często, ale miałem ten problem z Oracle i DBCP). Mój wzór jest taki (w starszej składni Java) to:

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

Teoretycznie nie jest w 100% idealny, ponieważ między sprawdzaniem stanu zamknięcia a samym zamknięciem jest trochę miejsca na zmianę stanu. W najgorszym przypadku dostaniesz ostrzeżenie na długo. - ale jest mniejsza niż możliwość zmiany stanu w zapytaniach długoterminowych. Używamy tego wzorca w produkcji z obciążeniem „przeciętnym” (150 jednoczesnych użytkowników) i nie mieliśmy z nim problemu - więc nigdy nie wyświetlaj tego komunikatu ostrzegawczego.