Perché dovremmo eseguire il rollback due volte prima di chiudere in un blocco finale?

1

Sto cercando di implementare la modifica della chiusura della connessione al database suggerita in questa domanda . Più di una volta, ho trovato questo blocco di codice alla fine dei miei blocchi di prova:

try {
    -Code-
} catch(DatabaseException de) {
    if(conn != null)
    try{ 
        conn.rollback(); 
    } catch(SQLException e) { }
    throw de;
} catch(SQLException se) {
    if(conn != null)
    try { 
        conn.rollback(); 
    } catch(SQLException e) { }
    throw new DatabaseException("SQLException caught: "+se.getMessage());
} finally{
    if(conn != null)
    try{ 
        conn.rollback();
        conn.rollback();
        conn.close(); 
    } catch(SQLException e) { }
}

Questo mi sconcerta assolutamente - perché dovremmo riavviare la nostra connessione due volte prima di chiuderla in un blocco Finally, quando stiamo già recuperando il rollback separatamente?

    
posta Zibbobz 10.06.2015 - 20:10
fonte

1 risposta

2

Ho già visto questo codice in un'altra lingua (Delphi). È stato implementato in questo modo a causa di un problema in cui il database (in questo caso Oracle 7 o 8) non eseguiva il rollback in modo affidabile la prima volta che veniva richiamato il metodo di rollback. Il bug era apparentemente casuale e non poteva essere riprodotto in modo affidabile - anche in produzione.

Invece di passare giorni a rintracciare Heisenbug, lo sviluppatore ha deciso di mettere un secondo rollback in cui "risolto" il problema. Ci siamo assicurati che questo fosse correttamente commentato per documentare l'hack.

IIRC si è mosso per utilizzare direttamente l'interfaccia di chiamata Oracle piuttosto che Borland Database Engine ha risolto il problema che indica che il problema è qualcosa di strano nel livello di astrazione del database.

    
risposta data 11.06.2015 - 06:16
fonte

Leggi altre domande sui tag