TransactionScope: evitare transazioni distribuite

Question

Ho un oggetto padre (parte di un DAL) che contiene, tra le altre cose, una raccolta (List<t>) di oggetti figlio.

Quando sto salvando l'oggetto nel DB, inserisco/aggiorno il genitore, quindi eseguo il ciclo di ciascun bambino. Per la manutenibilità, ho messo tutto il codice per il bambino in un metodo privato separato.

Stavo per utilizzare le transazioni ADO standard, ma durante i miei viaggi mi sono imbattuto nell'oggetto TransactionScope, che credo mi consenta di avvolgere tutta l'interazione DB nel metodo padre (insieme all'interazione nel metodo figlio) in una transazione.

Fin qui tutto bene ...?

Quindi la prossima domanda è come creare e utilizzare le connessioni all'interno di questo TransactionScope. Ho sentito dire che l'utilizzo di più connessioni, anche se si trovano nello stesso DB, può costringere TransactionScope a pensare che si tratti di una transazione distribuita (che implica un costoso lavoro di DTC).

È il caso? O è, come sembra che stia leggendo altrove, un caso che usa la stessa stringa di connessione (che si presterà al pooling di connessioni) andrà bene?

Più in pratica, posso ...

1. creare connessioni separate nel bambino genitore & (anche se con la stessa stringa di connessione)
2. creare una connessione nel genitore una farla passare attraverso un parametro (mi sembra goffo)
3. Fai qualcos'altro ...?

UPDATE:

Mentre sembra sarei OK usando la mia solita .NET3.5 + e SQL Server 2008+, un'altra parte di questo progetto verrà utilizzato Oracle (10g), così ho potrebbe anche praticare una tecnica che può essere utilizzata in modo coerente tra i progetti.

Quindi passerò semplicemente la connessione ai metodi figlio.

---

Opzione 1 codice di esempio:

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

Molti provider ADO di database (come Oracle ODP.NET) avviano effettivamente transazioni distribuite quando si utilizza TransactionScope per eseguire transazioni su più connessioni, anche quando condividono la stessa stringa di connessione.

Alcuni provider (come SQL2008 in .NET 3.5+) riconoscono quando viene creata una nuova connessione in un ambito di transazione che fa riferimento alla stessa stringa di connessione e non determinerà il funzionamento di DTC. Ma qualsiasi variazione nella stringa di connessione (come i parametri di ottimizzazione) potrebbe impedire che ciò si verifichi, e il comportamento tornerà ad utilizzare una transazione distribuita.

Sfortunatamente, l'unico mezzo affidabile per garantire che le transazioni lavorino insieme senza creare una transazione distribuita è quello di passare l'oggetto di connessione (o lo IDbTransaction) ai metodi che devono "continuare" sulla stessa transazione.

A volte aiuta ad elevare la connessione a un membro della classe in cui si sta svolgendo il lavoro, ma questo può creare situazioni imbarazzanti e complica il controllo della durata e dello smaltimento dell'oggetto di connessione (poiché generalmente preclude l'utilizzo della dichiarazione using).

Answer 2

Nel tuo esempio il TransactionScope è ancora nel contesto di un metodo, si potrebbe semplicemente creare uno SqlTransaction con più comandi sotto quello. Utilizzare TransactionScope se si desidera spostare la transazione da un metodo, ad esempio, il chiamante di tale metodo o se si accede a più database.

Aggiornamento: non importa, ho appena individuato la chiamata figlio. In questa situazione, è possibile passare l'oggetto connessione a classi figlio. Inoltre, non è necessario disporre manualmente di TransactionScope - l'utilizzo di blocchi si comporta come i blocchi try-finally e consente di eseguire lo smaltimento anche in caso di eccezioni.

Aggiornamento 2: meglio ancora, passare IDbTransaction alla classe figlio. La connessione può essere recuperata da quello.

Answer 3

Empiricamente, ho stabilito che (per il provider di SQL Server) se il processo può usufruire di pool di connessioni per condividere la connessione (e l'operazione) tra i processi padre e figlio, il DTC non necessariamente diventerà coinvolti.

Questo è un grande "se", però, secondo il vostro esempio, il collegamento creato dal processo genitore non può essere condiviso dai processi figli (non si chiude/rilasciare la connessione prima di richiamare i processi figli). Ciò comporterà una transazione che si estende su due connessioni effettive, il che comporterà la promozione della transazione a una transazione distribuita.

Sembra che sarebbe facile rifattorizzare il codice per evitare questo scenario: basta chiudere la connessione creata dal processo padre prima di richiamare i processi figli.