TransactionScope: evitar transacciones distribuidas

Question

Tengo un objeto principal (parte de un DAL) que contiene, entre otras cosas, una colección (List<t>) de objetos secundarios.

Cuando guardo el objeto en la base de datos, ingreso/actualizo el elemento primario y luego recorro cada elemento secundario. Para la mantenibilidad, he puesto todo el código para el niño en un método privado separado.

Iba a utilizar transacciones ADO estándar, pero en mis viajes tropecé con el objeto TransactionScope, que creo que me permitirá ajustar todas las interacciones DB en el método padre (junto con todas las interacciones en el método secundario) en una transacción

Hasta ahora todo bien ..?

Así que la siguiente pregunta es cómo crear y usar conexiones dentro de este TransactionScope. He oído que el uso de conexiones múltiples, incluso si están en la misma base de datos, puede obligar a TransactionScope a pensar que se trata de una transacción distribuida (que implica un costoso trabajo de DTC).

¿Es el caso? ¿O es que, como parece estar leyendo en otro lado, un caso que usar la misma cadena de conexión (que se prestará a la agrupación de conexiones) estará bien?

Más prácticamente hablando, puedo ...

1. crear conexiones separadas en el niño los padres & (aunque con la misma cadena de conexión)
2. crear un enlace en la matriz a través de un pase de como parámetro (me parece torpe)
3. ¿Hace algo más ...?

ACTUALIZACIÓN:

Aunque parece que iba a estar bien usando mi .NET3.5 habitual + y SQL Server 2008+, otra parte de este proyecto va a utilizar Oracle (10g) por lo que también podría practicar una técnica que pueda usarse de manera consistente en todos los proyectos.

Así que simplemente pasaré la conexión a través de los métodos secundarios. 1 Código

---

opción de la muestra:

using (TransactionScope ts = new TransactionScope()) 
      { 
       using (SqlConnection conn = new SqlConnection(connString)) 
       { 
        using (SqlCommand cmd = new SqlCommand()) 
        { 
         cmd.Connection = conn; 
         cmd.Connection.Open(); 
         cmd.CommandType = CommandType.StoredProcedure; 

         try 
         { 
          //create & add parameters to command 

          //save parent object to DB 
          cmd.ExecuteNonQuery(); 

          if ((int)cmd.Parameters["@Result"].Value != 0) 
          { 
           //not ok 
           //rollback transaction 
           ts.Dispose(); 
           return false; 
          } 
          else //enquiry saved OK 
          { 
           if (update) 
           { 
            enquiryID = (int)cmd.Parameters["@EnquiryID"].Value; 
           } 

           //Save Vehicles (child objects) 
           if (SaveVehiclesToEPE()) 
           { 
            ts.Complete(); 
            return true; 
           } 
           else 
           { 
            ts.Dispose(); 
            return false; 
           } 
          } 
         } 
         catch (Exception ex) 
         { 
          //log error 
          ts.Dispose(); 
          throw; 
         } 
        } 
       } 
      } 

Answer 1

Muchos proveedores de bases de datos ADO (como Oracle ODP.NET) comienzan transacciones distribuidas cuando usa TransactionScope para realizar transacciones a través de varias conexiones, incluso cuando comparten la misma cadena de conexión.

Algunos proveedores (como SQL2008 en .NET 3.5+) reconocen cuándo se crea una nueva conexión en un ámbito de transacción que hace referencia a la misma cadena de conexión y no da como resultado el trabajo de DTC. Pero cualquier variación en la cadena de conexión (como los parámetros de ajuste) puede impedir que esto ocurra, y el comportamiento volverá a usar una transacción distribuida.

Desafortunadamente, la única manera confiable de asegurar que sus transacciones funcionen juntas sin crear una transacción distribuida es pasar el objeto de conexión (o el IDbTransaction) a métodos que necesitan "continuar" en la misma transacción.

A veces ayuda elevar la conexión a un miembro de la clase en la que está haciendo el trabajo, pero esto puede crear situaciones incómodas y complica el control de la vida útil y la eliminación del objeto de conexión (ya que generalmente excluye el uso de la declaración using).

Answer 2

En su ejemplo la TransactionScope se encuentra todavía en el contexto de un método, usted podría simplemente crear un SqlTransaction con múltiples comandos debajo de eso. Use TransactionScope si desea mover la transacción fuera de un método, para decir, la persona que llama de ese método, o si accede a múltiples bases de datos.

Actualización: no importa Acabo de ver la llamada de un niño. En esta situación, podría pasar el objeto de conexión a clases secundarias. Además, no es necesario que deseche manualmente el TransactionScope, ya que los bloques actúan como bloques try-finally y ejecutarán el desecho incluso con excepciones.

Actualización 2: mejor aún, pase el IDbTransaction a la clase secundaria. La conexión se puede recuperar de eso.

Answer 3

Empíricamente, he determinado que (por el proveedor de SQL Server) si el proceso puede tomar ventaja de la agrupación de conexiones para compartir la conexión (y la transacción) entre los procesos padre e hijo, el DTC no necesariamente va a convertirse involucrado.

Este es un gran "si", sin embargo, según su ejemplo, la conexión creada por el proceso principal no puede ser compartida por los procesos secundarios (no cierra/libera la conexión antes de invocar los procesos secundarios). Esto dará lugar a una transacción que abarca dos conexiones reales, lo que dará lugar a que la transacción se promueva a una transacción distribuida.

Parece que sería fácil refactorizar su código para evitar este escenario: simplemente cierre la conexión creada por el proceso principal antes de invocar los procesos secundarios.