I set di risultati e le dichiarazioni JDBC devono essere chiusi separatamente anche se in seguito la connessione viene chiusa?

Si dice che sia una buona abitudine chiudere tutte le risorse JDBC dopo l'uso. Ma se ho il seguente codice, è necessario chiudere il gruppo di risultati e la dichiarazione?

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

La domanda è se la chiusura della connessione fa il lavoro o se lascia alcune risorse in uso.

Quello che hai fatto è una pratica perfetta e molto buona.

Il motivo per cui dico la sua buona pratica ... Ad esempio, se per qualche motivo stai usando un tipo "primitivo" di pooling di database e chiami connection.close(), la connessione verrà restituita al pool e il ResultSet/ Statementnon verrà mai chiuso e quindi tu incontrerà molti nuovi problemi diversi!

Quindi non puoi sempre contare su connection.close()per ripulire.

Spero che aiuti :)

Java 1.7 ci semplifica la vita grazie alla dichiarazione 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.
    }
}

Questa sintassi è piuttosto breve ed elegante. E connectionsarà davvero chiuso anche quando statementnon è stato possibile crearlo.

Dai javadocs :

Quando un Statementoggetto viene chiuso, anche il suo ResultSetoggetto corrente , se esistente, viene chiuso.

Tuttavia, i javadocs non sono molto chiari sul fatto che Statemente ResultSetsiano chiusi quando si chiude il sottostante Connection. Dichiarano semplicemente che la chiusura di una connessione:

Rilascia Connectionimmediatamente il database di questo oggetto e le risorse JDBC invece di attendere il loro rilascio automatico.

A mio avviso, sempre esplicitamente vicino ResultSets, Statementse Connectionsquando hai finito con loro come l'implementazione di closepuò variare tra i driver di database.

Puoi risparmiare un sacco di codice sulla piastra della caldaia usando metodi come closeQuietlyin DBUtils di Apache.

Ora sto usando Oracle con Java. Ecco il mio punto di vista:

Si dovrebbe chiudere ResultSete Statementin modo esplicito perché Oracle ha problemi in precedenza con mantenere i cursori aperti anche dopo la chiusura della connessione. Se non si chiude il ResultSet(cursore), verrà generato un errore come il numero massimo di cursori aperti superato .

Penso che potresti riscontrare lo stesso problema con altri database che usi.

Ecco il tutorial Chiudi ResultSet al termine :

Chiudi Risultato Impostato al termine

Chiudi ResultSetoggetto non appena si finisce di lavorare con l' ResultSetoggetto anche se l' Statementoggetto chiude ResultSetimplicitamente l' oggetto quando si chiude, la chiusura ResultSetesplicita dà la possibilità al garbage collector di recuperare la memoria il prima possibile perché l' ResultSetoggetto può occupare molta memoria a seconda della query.

ResultSet.close();

Se vuoi un codice più compatto, ti suggerisco di usare Apache Commons DbUtils . In questo caso:

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

Il metodo corretto e sicuro per chiudere le risorse associate a JDBC questo (tratto da Come chiudere correttamente le risorse JDBC - Ogni volta ):

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

Non importa se Connectionè raggruppabile o meno. Anche la connessione poolable deve essere pulita prima di tornare al pool.

"Pulito" di solito significa chiudere i set di risultati e ripristinare eventuali transazioni in sospeso ma non chiudere la connessione. Altrimenti il ​​pool perde il suo senso.

No, non è necessario chiudere nulla MA la connessione. Secondo le specifiche JDBC, la chiusura di qualsiasi oggetto superiore chiuderà automaticamente gli oggetti inferiori. La chiusura Connectionchiuderà qualsiasi Statements creato dalla connessione. Chiudendo qualsiasi Statementsi chiuderanno tutti gli ResultSets che sono stati creati da quello Statement. Non importa se Connectionè raggruppabile o meno. Anche la connessione poolable deve essere pulita prima di tornare al pool.

Ovviamente potresti avere lunghi cicli nidificati sulla Connectioncreazione di molte istruzioni, quindi chiuderle è appropriato. Non mi chiudo quasi mai ResultSet, sembra eccessivo quando si chiude Statemento Connectionli chiuderò .

Ho creato il seguente metodo per creare One Liner riutilizzabile:

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

Uso questo codice in una classe padre ereditata da tutte le mie classi che inviano query DB. Posso usare l'Oneliner su tutte le query, anche se non ho un resultSet. Il metodo si occupa di chiudere ResultSet, Statement, Connection nell'ordine corretto. Ecco come appare il mio blocco finalmente.

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

Per quanto ricordo, nell'attuale JDBC, i set di risultati e le istruzioni implementano l'interfaccia AutoCloseable. Ciò significa che vengono chiusi automaticamente dopo essere stati distrutti o usciti dal campo di applicazione.

Alcune funzioni utili:

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

Con il modulo Java 6 penso sia meglio verificare che sia chiuso o meno prima di chiudere (ad esempio se un pool di connessioni sfrutta la connessione in un altro thread) - ad esempio qualche problema di rete - l'istruzione e lo stato del gruppo di risultati possono essere chiusi. (non succede spesso, ma ho avuto questo problema con Oracle e DBCP). Il mio modello è che (nella vecchia sintassi 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());
        }
    }
}

In teoria non è perfetto al 100% perché tra il controllo dello stato vicino e la stessa chiusura c'è un piccolo spazio per il cambiamento di stato. Nel peggiore dei casi riceverai un avviso a lungo. - ma è inferiore alla possibilità di cambio di stato nelle query a lungo termine. Stiamo usando questo modello in produzione con un carico "medio" (150 utenti simultanei) e non abbiamo avuto problemi con esso - quindi non vedere mai quel messaggio di avviso.