TransactionScope, ¡ha venido para quedarse!

Todas las aplicaciones que desarrollo en mi empresa están orientadas a datos. De este modo, una de mis grandes preocupaciones es como gestionar de forma eficiente las transacciones en el acceso a datos. Hasta ahora, siempre había utilizado el objeto SqlTransaction para llevar a cabo esta tarea, pero lo cierto es que no estoy del todo satisfecho con su uso. Para intentar argumentar porque no quiero SqlTransaction, primero veamos un ejemplo de cómo utilizar este objeto.

    Sub Main()

        Using cnn As New SqlConnection("Data Source=SERGIO-VAIO;Initial Catalog=Pedidos;Integrated Security=True")

            cnn.Open()

            Dim tran As SqlTransaction = Nothing

            Try

                tran = cnn.BeginTransaction

                InsertarPrimerCliente(cnn, tran)

                InsertarSegundoCliente(cnn, tran)

                tran.Commit()

            Catch ex As Exception

                If Not tran Is Nothing Then

                    tran.Rollback()

                End If

                Console.WriteLine(ex.Message)

            Finally

                Console.ReadLine()

            End Try

        End Using

    End Sub

 

    Sub InsertarPrimerCliente(ByVal cnn As SqlConnection, ByVal tran As SqlTransaction)

        Dim cmdText As String = "INSERT INTO Clientes VALUES (1, 'Cliente 1')"

        Using cmd As New SqlCommand(cmdText, cnn, tran)

            cmd.ExecuteNonQuery()

        End Using

    End Sub

 

    Sub InsertarSegundoCliente(ByVal cnn As SqlConnection, ByVal tran As SqlTransaction)

        Dim cmdText As String = "INSERT INTO Clientes VALUES (2, 'Cliente 2')"

        Using cmd As New SqlCommand(cmdText, cnn, tran)

            cmd.ExecuteNonQuery()

        End Using

    End Sub

 

Realmente este código no me gusta porque los métodos “InsertarPrimerCliente” e “InsertarSegundoCliente” tienen que recibir como parámetros tanto el objeto SqlConnection como el objeto SqlTransaction. Esto es así porque si quiero que los comandos ejecutados desde estos métodos y contra la base de datos participen todos en la misma transacción, tiene que compartir tanto la misma conexión como la misma transacción.

Creo que es fácil entender que la dependencia de este modelo transaccional en ADO.NET implica mantener siempre viva la referencia tanto al objeto SqlConnection como al objeto SqlTransaction. Ahora imagina, no 2 métodos, sino X métodos en distintas clases, distintos ensamblados, etc. No sé, en mi opinión, en el momento que tu código transaccional ya no es sólo una sencilla llamada a un único método con un principio y fin concreto, este modelo en vez de ayudarme, me la hace la vida más difícil.

De hecho, si por ejemplo sólo pasamos a los métodos el objeto SqlConnection, pero no el objeto SqlTransaction, obtendremos este bonito error que para mí ya es todo un clásico:
“ExecuteNonQuery requiere que el comando tenga una transacción cuando la conexión asignada al mismo está en una transacción local pendiente. No se ha inicializado la propiedad Transaction del comando.”.
Por otro lado, si directamente no pasamos ni la conexión ni la transacción, nuestros comandos en métodos como los expuestos serán simple y llanamente una nueva conexión sin intervenir en el contexto de ninguna transacción.

Para solucionar esto, hemos ideado en nuestro empresa un contexto ficticio de conexión y transacción que mejor o peor funciona y evita tener que pasar constantemente estos parámetros (SqlConnection y SqlTransaction), pero aún así es una carga extra de diseño en cualquier programa que hay que soportar y por supuesto no está exenta de errores ni de posibles refactorizaciones.

En este punto creí que todo estaba perdido hasta que descubrí el objeto TransactionScope.

Ahora, el anterior código pasaría a ser este otro:

Sub Main()

        Using tran As New Transactions.TransactionScope

                Try

                    InsertarPrimerCliente()

                    InsertarSegundoCliente()

                    tran.Complete()

                Catch ex As Exception

                    Console.WriteLine(ex.Message)

                End Try

        End Using

        Console.ReadLine()

    End Sub

 

    Sub InsertarPrimerCliente()

        Using cnn As New SqlConnection("Data Source=SERGIO-VAIO;Initial Catalog=Pedidos;Integrated Security=True")

            cnn.Open()

            Dim cmdText As String = "INSERT INTO Clientes VALUES (1, 'Cliente 1')"

            Using cmd As New SqlCommand(cmdText, cnn)

                cmd.ExecuteNonQuery()

            End Using

        End Using

    End Sub

 

    Sub InsertarSegundoCliente()

        Using cnn As New SqlConnection("Data Source=SERGIO-VAIO;Initial Catalog=Pedidos;Integrated Security=True")

            cnn.Open()

            Dim cmdText As String = "INSERT INTO Clientes VALUES (2, 'Cliente 2')"

            Using cmd As New SqlCommand(cmdText, cnn)

                cmd.ExecuteNonQuery()

            End Using

        End Using

    End Sub

 

Si nos fijamos, ahora simplemente “iniciamos un contexto transaccional” y a partir de aquí cualquier comando ejecutado contra esa misma conexión o contra cualquier otra nueva conexión será ejecutado de forma automática en el contexto de la misma “transacción de ambiente” (más adelante veremos que se puede configurar esto, pero en principio este es el comportamiento predeterminado). Por otro lado, sólo hay que controlar el éxito de la operación para llamar al método Complete, mientras que para anular, revertir, deshacer o rechazar la transacción (hoy estoy que lo tiro con los sinónimos), simplemente se hará automáticamente si al salir de la instrucción Using donde se declaró el objeto TransactionScope no se llamó de forma explícita al método Complete.

Para la utilización de TransactionScope es necesario agregar una referencia a System.Transactions.
Esta referencia sólo es necesario en los proyectos que hacen referencia explícita al objeto TransactionScope. Si por ejemplo la función “InsertarPrimerCliente” estuviera en una biblioteca de clases, participaría de la transacción pero no sería necesario agregar la referencia a System.Transactions porque no la utiliza de forma explícita.

Realmente, TransactionScope utiliza MSDTC (Microsoft Data Transaction Coordinator, coordinador de transaciones distribuidas) para llevar a cabo su tarea. De hecho y donde radica principalmente la potencia de TransactionScope (más allá de su facilidad de uso frente a SqlTransaction) es que es capaz de incluir en misma transacción, operaciones contra distintos orígenes de base de datos o recursos transaccionales (por ejemplo las colas también son transaccionables). Eso significa que en nuestro ejemplo anterior, “InsertarPrimerCliente” podría haber insertado en una base de datos A, mientras que “InsertarSegundoCliente” podría haberlo hecho en una base de datos B, todo ello en una misma transacción que se completaría o rechazaría como una operación ACID.

Algo importante es que si estamos utilizando una sola base de datos en nuestra transacción, sólo tenemos una conexión abierta a la vez y además no tenemos transacciones anidadas (todos estos requisitos se cumplen en el ejemplo anterior), TransactionScope utilizará una “transacción ligera” gestionada por LTM (Lightweight Transaction Coordinator), pero en el momento en que utilicemos 2 o más base de datos, las cadenas de conexión sean distintas (aunque finalmente apunten a la misma base de datos y servidor) o anidemos transacciones, la transacción ligera será promocionada a MSDTC.  Además, todo lo anterior se cumple en SQL Server 2008, pero en versiones anteriores (2005) incluso abrir 2 conexiones simultaneas a la misma base de datos y con la misma cadena de conexión, también promocionará la transacción, ver más en Avoid unwanted Escalation to Distributed Transactions

Cuando decía que hay que tener cuidado con las cadenas de conexión me refería a que si accedemos a nuestra única base de datos (en la que suponemos será gestionada por LTM) pero con distintas cadenas de conexión, entonces TransactionScope pensará que son distintas base de datos y pasará a ser una transacción gestionada por MSDTC.

Para ver esto lo mejor será un ejemplo. Simplemente cambiaremos la cadena de conexión de “InsertarPrimerCliente” a otra cadena de conexión válida para la misma base de datos y observaremos como ahora pasamos de LTM a MSDTC.

InsertarPrimerCliente	Data Source=SERGIO-VAIO;Initial Catalog=Pedidos;User Id=sa;Password=XX
InsertarSegundoCliente	Data Source=SERGIO-VAIO;Initial Catalog=Pedidos;Integrated Security=True

 

Sobra decir que está claro que la transacción ha sido promovida a MSDTC, ¡si es un perro nos muerde!, pero además vemos como hemos recibido un error que nos informa de que MSDTC no está disponible en nuestro equipo. Aunque podría ser más complicado, inicialmente para configurar MSDTC tienes que abrir “Servicios de componentes” y en las propiedades de DTC local, activar el checkbox “Permitir clientes remotos”.

Una vez ya tenemos configurado MSDTC, las transacciones promovidas podemos visualizarlas también en “Servicios de componentes”. Vamos a poner un Console.ReadLine() antes de llamar a Complete() para poder ver esto.

Lo que hemos hecho hasta ahora ha sido romper el hielo con el tema de TransactionScope, pero ahora debemos ver unas cuantas opciones más en lo relativo a su uso que cerrarán el círculo y nos permitirán tener mayor control sobre cómo y cuándo suceden las cosas.

Todos los ejemplos vistos han utilizando la instrucción Using, diciendo que si al salir de ella aún no se ha llamado al método Complete() los cambios serán rechazados. Esto es totalmente cierto, pero también es totalmente cierto que no es necesario utilizar Using (aunque si recomendable) puesto que Using lo único que asegura es que se llama siempre al método Dispose(). Pues bien, es en ese método donde se haya toda la lógica de rechazo de la transacción, así que si tienes la necesidad de usar TransactionScope sin Using, simplemente llama a Dispose() y obtendrás la misma funcionalidad que con Using.

La clase TransactionOptions permite especificar el comportamiento de la transacción. Por ejemplo, la propiedad Timeout especifica el tiempo de espera máximo de la transacción antes de que sea abortada automáticamente, mientras que la propiedad IsolationLevel especifica el nivel aislamiento de la transacción.

Y ahora viene en mi opinión la parte más importante y que es precio entender para manejar correctamente TransactionScope y es la relación entre la transacción de ambiente con siguientes nuevas transacciones declaradas en el código. Veamos esto con un ejemplo:

        Using cnn As New SqlConnection("Data Source=SERGIO-VAIO;Initial Catalog=Pedidos;Integrated Security=True")

            cnn.Open()

            Using tran1 As New TransactionScope

                InsertarPrimerCliente()

                Using tran2 As New TransactionScope

                    InsertarSegundoCliente()

                    tran2.Complete()

                End Using

                tran1.Complete()

            End Using

        End Using

 

En este ejemplo podemos ver como hay 2 TransactionScope, una de ellas anidada dentro de otra (haz esto extensible a llamadas entre métodos, etc.). ¿Cómo se comporta entonces la segunda transacción?

Primero decir que la siguientes instrucciones son equivalentes:

Using tran As New TransactionScope()

 

Using tran As New TransactionScope(TransactionScopeOption.Required)

 

Cuando declaramos un nuevo objeto TransactionScope podemos definir su comportamiento respecto a una posible transacción de ambiente existente. El valor predeterminado es Required, pero veamos que valores puede tomar esta opción:

Required	El ámbito requiere una transacción. Utiliza una transacción de ambiente si ya existe una. De lo contrario, crea una nueva transacción antes de introducir el ámbito. Éste es el valor predeterminado.
RequiresNew	Siempre se crea una nueva transacción para el ámbito.
Supress	Se suprime el contexto de transacción de ambiente al crear el ámbito. Todas las operaciones dentro del ámbito se realizan sin un contexto de transacción de ambiente.

 

Esto traducido al español es:

Required	Si hay una transacción de ambiente la utilizaré sino crearé una nueva.
RequiresNew	Me da igual si hay o no hay una transacción de ambiente, yo a mi bola en una nueva transacción.
Supress	Paso de transacciones, soy un machote y no quiero ejecutarme en el contexto de ninguna transacción.

 

Cabe mencionar que todos estos ejemplos lo estoy realizando con SQL Server 2008 y al menos esta versión soporta perfectamente transacciones anidadas, por lo que por ejemplo si la transacción externa es Required y la interna RequiresNew se crearán 2 transacciones (esto es 2 BEGIN TRANSACTION en SQL Server).

Por último, un par de apuntes sobre el método Complete y sobre como averiguar si nuestro código está en el contexto de una transacción y en qué transacción.

• Si se llama a Complete para la misma instancia de TransactionScope 2 o más veces, excepto la primera, las siguientes fallarán con System.InvalidOperationException.
• Si se llama a Complete desde una transacción anidada especificada como Required (ámbito predeterminado), realmente no se está confirmando la transacción y no tiene por ahora ningún efecto en la misma, sólo la llamada a Complete de la transacción de ambiente (la más externa) será la que confirma o rechace los cambios.
• La propiedad Transaction.Current nos devuelve (también sirve para establecer) la transacción de ambiente. Además también nos devuelve información sobre la transacción ¿Recuerdas ese maravillo GUID que salía en “Servicios de componentes” como identificador de la transacción activa?.

Bueno, la verdad es que este post podría continuar y continuar, pero por hoy ya es suficiente.

Lo dicho, TransactionScope ha venido para quedarse.

Un saludo!