c# - una - transacciones sql commit

¿Es necesaria la reversión de la transacción explícita?

Question

Muchos ejemplos por ahí abogan por la reversión explícita de las transacciones de base de datos, en la línea de:

using (var transaction = ...)
{
    try
    {
        // do some reading and/or writing here

        transaction.Commit();
    }
    catch (SqlException ex)
    {
        // explicit rollback
        transaction.Rollback();
    }
}

Sin embargo, tiendo a hacer esto:

using (var transaction = ...)
{
    // do some reading and/or writing here

    transaction.Commit();
}

Cuando se produce una excepción, solo confío en la reversión implícita de las transacciones que no se han confirmado.

¿Hay algún problema que confíe en este comportamiento implícito? ¿Alguien tiene una razón convincente por la que no debería hacerlo de esta manera?

Answer 1

No, no es específicamente necesario, sin embargo, puedo pensar en dos razones por las que podría ser una buena idea:

• Claridad

Algunos podrían argumentar que usar transaction.Rollback() hace más claro en qué circunstancias no se realizará la transacción.

• Liberando cerraduras

Cuando se trata de transacciones, es importante darse cuenta de que ciertos bloqueos solo se liberarán cuando la transacción se revierta o se confirme. Si está utilizando la instrucción de using , la transacción se retrotraerá cuando se elimine la transacción, sin embargo, si por algún motivo necesita realizar algún manejo de errores dentro del bloque de using , puede ser conveniente revertir la transacción (eliminar los bloqueos). ) antes de realizar un manejo de errores complejo / lento.

Answer 2

Siempre y cuando la transacción sea totalmente autónoma en el bloque using (), estará listo. Sin embargo, los problemas pueden surgir, y de hecho, si alguien recibe una llamada de un objeto de transacción existente. Pero eso es un escenario diferente ...

Answer 3

Supongo que podría responderse que el primer enfoque es más legible para alguien que mantiene su código. La naturaleza explícita de la codificación hace que los objetivos sean claros y rápidos. Si bien la reversión implícita es clara para usted, y probablemente para cualquiera que tenga un conocimiento más que pasado del manejo de transacciones, puede que no lo sea para otros. Dicho esto, unos pocos comentarios lo rectificarían rápidamente. La única preocupación es si la reversión implícita no es una característica documentada del objeto.

Por lo tanto, diría que, siempre que comente la operación y puede confiar en la acción implícita, entonces no hay una buena razón para optar por el enfoque explícito.

Answer 4

Veo dos problemas con su uso:

1. Confía en el método Dispose () de la transacción para revertir una transacción no confirmada, creando una dependencia en la implementación de IDisposable de un tercero. Es un riesgo insignificante en este caso, por supuesto, pero no es una buena práctica.
2. Se está perdiendo la oportunidad de iniciar sesión y / o manejar la excepción. Además, atraparía Exception no SqlException.

Answer 5

La mayoría de las conexiones ADO.NET escritas correctamente revertirán las transacciones no confirmadas explícitamente. Así que no es estrictamente necesario.

El principal beneficio que veo de un Rollback() explícito lo llama la capacidad de establecer un punto de interrupción allí y luego inspeccionar la conexión o la base de datos para ver qué estaba pasando. También es más claro para los futuros mantenedores del código lo que sucede bajo diferentes rutas de ejecución.