Why would we need to rollback twice before closing in a finally block?

Question

I'm trying to implement the change in database connection closing suggested in this question's answers. More than once, I've come across this block of code at the end of my try blocks:

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

This absolutely baffles me - why would we need to rollback our connection twice before closing it in a Finally block, when we're already catching the rollback separately?

Answer 1

I have seen this code before in another language (Delphi). It was implemented that way because of an issue where the database (in this case Oracle 7 or 8) wouldn't reliably rollback the first time the rollback method was called. The bug was seemingly random and could not be reliably reproduced - even in production.

Rather than spending days tracking down the Heisenbug the developer decided to put a second rollback in which "fixed" the problem. We made sure that this was properly commented to document the hack.

IIRC moving to directly use the Oracle Call Interface rather than the Borland Database Engine resolved the issue which points to the problem being something weird in the database abstraction layer.