statement - java executeupdate parameter

¿Es necesaria la reversión si java.sql.Connection#commit() lanza una excepción?

Question

De acuerdo con la documentación de JAVA , Connection#commit() puede lanzar SQLException . Mi pregunta es si se debe emitir o no una reversión en este escenario.

Por ejemplo:

Connection con = null;
try {
// assume this method returns an opened connection with setAutoCommit(false)
con = createConnection();
// do DB stuff
con.commit();
} catch (SQLException e) {
if (con != null) {
// what if con.commit() failed, is this still necessary,
// will it hurt anything?
con.rollback();
}
} finally {
if (con != null) {
con.close();
}
}

De hecho, envolví la llamada con.rollback () en otro método que ignora cualquier excepción lanzada por él, así que creo que estoy bien aquí. Solo me preguntaba si esta era la mejor manera de manejar las cosas.

Answer 1

"¿Devuelve una conexión abierta?" Si esa conexión se comparte en un grupo (y podría ser en el futuro) no desea que otra transacción confirme su trabajo anterior. He visto MUCHOS casos de clientes / soluciones de conectar un controlador de conexión agrupada que cumple con las interfaces JDBC y Connection.close() también se puede usar para devolver la Conexión a una agrupación.

Además, es mejor que try{}catch{} tu rollback() (edita, solo lee tu publicación completa, pero siempre me gusta registrar una excepción en rollback)

Answer 2

Haría una reversión explícita solo para fines de limpieza. Aunque los cambios no se mantendrán en db de ninguna manera, parece bueno dejar que la base de datos sepa explícitamente que ya ha terminado aquí. Al igual que la forma en que se cierra la conexión explícitamente, sin esperar a que el objeto Connection se recoja.

Esto, obviamente, no es una respuesta técnica y también me interesaría saber si hay un punto práctico para hacerlo.

Answer 3

La forma habitual en que hago esto es:

boolean bSuccess = false;
Connection con = null;
try {
// assume this method returns an opened connection with setAutoCommit(false)
con = createConnection();
// do DB stuff
bSuccess = true;
} catch (SQLException e)
{
}
finally
{
try
{
if (con != null)
{
if(bSuccess)
con.commit()
else
con.rollback();
con.close();
}
}
catch(SQLException sqle)
{
log("Log the error here");
// do nothing we tried
}
}

Dicho esto, nunca he visto fallar un commit o rollback si las consultas funcionaron.
Si tiene transacciones pendientes, la mayoría de las bases de datos tienen herramientas para liberarlas. La mayoría de los servidores de aplicaciones continuarán reintentando las confirmaciones y retrocesos hasta que puedan conectarse.

Es posible que desee ver esta publicación: ¿Es necesario escribir ROLLBACK si las consultas fallan?

Answer 4

La reversión es importante incluso si la confirmación falló, de acuerdo con los documentos de Java 1.6 JDBC :

Se recomienda encarecidamente que una aplicación confirme o deshaga explícitamente una transacción activa antes de llamar al método de cierre. Si se llama al método de cierre y hay una transacción activa, los resultados están definidos por la implementación.

Esto significa que si no invoca explícitamente la reversión, alguna implementación de JDBC podría invocar el compromiso antes de cerrar la conexión.

Otra buena razón para revertir es como Xepoch sugirió y cuando se usa un grupo de conexiones es aún más importante. Al obtener una conexión de un grupo de conexiones, la mayoría de las implementaciones ejecutarán connection.setAutoCommit(defaultAutoCommit) antes de brindarle la conexión y de acuerdo con los JavaDocs:

Si se llama a este método durante una transacción y se cambia el modo de confirmación automática, la transacción se confirma

Si connection.rollback() lanza una excepción, entonces es un problema difícil ...