W naszym projekcie używamy TransactionScope, aby zapewnić, że nasza warstwa dostępu do danych wykonuje swoje akcje w transakcji. Naszym celem jest Nie Wymaganie włączenia usługi MSDTC na maszynach naszych użytkowników końcowych.

Problem polega na tym, że na połowie naszych maszyn programistycznych możemy działać z wyłączonym MSDTC. Druga połowa musi mieć włączone lub dostać "MSDTC na [serwer] jest niedostępny" komunikat o błędzie.

To naprawdę mnie drapie po głowie i ma mnie poważnie rozważając powrót do domowego rozwiązania transakcyjnego opartego na ADO.NET obiekty transakcji. To pozornie szaleństwo - ten sam kod, który działa (i nie eskaluje) na połowie naszych programistów , eskaluje na innych programistów.]}

Liczyłem na lepszą odpowiedź na prześledzenie, dlaczego transakcja jest eskalowana do DTC , ale niestety tak nie jest.

Oto przykładowy fragment kodu, który spowoduje kłopoty, na maszynach, które próbują aby eskalować, próbuje eskalować na drugim połączeniu.Open () (i tak, nie ma innego połączenia otwartego w tym czasie.)

using (TransactionScope transactionScope = new TransactionScope() {
   using (SqlConnection connection = new SqlConnection(_ConStr)) {
      using (SqlCommand command = connection.CreateCommand()) {
         // prep the command
         connection.Open();
         using (SqlDataReader reader = command.ExecuteReader()) {
            // use the reader
            connection.Close();
         }
      }
   }

   // Do other stuff here that may or may not involve enlisting 
   // in the ambient transaction

   using (SqlConnection connection = new SqlConnection(_ConStr)) {
      using (SqlCommand command = connection.CreateCommand()) {
         // prep the command
         connection.Open();  // Throws "MSDTC on [SERVER] is unavailable" on some...

         // gets here on only half of the developer machines.
      }
      connection.Close();
   }

   transactionScope.Complete();
}

• Dev 1: Windows 7 x64 sql2008
• Dev 2: Windows 7 x86 sql2008
• Dev 3: Windows 7 x64 SQL2005 SQL2008

Programiści, na których nie działa:

• Dev 4: Windows 7 x64, SQL2008 SQL2005
• Dev 5: Windows Vista x86, SQL2005
• Dev 6: Windows XP X86, SQL2005
• mój komputer domowy: Windows Vista Home Premium, x86, SQL2005

Powinienem dodać, że wszystkie maszyny, W celu wytropienia problemu, zostały w pełni załatane ze wszystkim, co jest dostępne z Microsoft Update.

Update 1:

• http://social.msdn.microsoft.com/forums/en-US/windowstransactionsprogramming/thread/a5462509-8d6d-4828-aefa-a197456081d3/ opisuje podobny problem...w 2006 roku!
• http://msdn.microsoft.com/en-us/library/system.transactions.transactionscope%28VS.80%29.aspx- przeczytaj ten przykład kodu, wyraźnie pokazuje zagnieżdżone drugie połączenie (w rzeczywistości z drugim serwerem SQL), które eskaluje do DTC. Nie robimy tego w naszym kod - nie używamy różnych serwerów SQL, ani różnych łańcuchów połączeń, ani nie mamy zagnieżdżonych połączeń drugorzędnych - nie powinno być eskalacji do DTC .
• http://davidhayden.com/blog/dave/archive/2005/12/09/2615.aspx (od 2005) mówi o tym, jak eskalacja do DTC zawsze będzie miała miejsce podczas łączenia się z SQL2000. Używamy SQL2005 / 2008
• http://msdn.microsoft.com/en-us/library/ms229978.aspx MSDN o transakcji eskalacja.

Strona eskalacji transakcji MSDN stwierdza, że następujące warunki spowodują eskalację transakcji do DTC:

1. co najmniej jeden trwały zasób, który nie obsługuje powiadomień jednofazowych, jest uwzględniony w transakcji.
2. do transakcji włączono co najmniej dwa trwałe zasoby obsługujące powiadomienia jednofazowe. Na przykład nawiązanie pojedynczego połączenia nie powoduje promocji transakcji. Jednakże, za każdym razem, gdy otwierasz drugie połączenie z bazą danych, powodując, że baza danych się zaciąga, System.Infrastruktura transakcji wykrywa, że jest to drugi trwały zasób w transakcji i eskaluje go do transakcji MSDTC.
3. wywoływane jest żądanie "marshal" transakcji do innej domeny aplikacji lub innego procesu. Na przykład serializacja obiektu transakcji przez granicę domeny aplikacji. Obiekt transakcji jest skalowany według wartości, oznacza to, że każda próba przekroczenia granicy domeny aplikacji (nawet w tym samym procesie) powoduje serializację obiektu transakcji. Obiekty transakcji można przekazać poprzez wywołanie zdalnej metody, która przyjmuje transakcję jako parametr lub można spróbować uzyskać dostęp do zdalnego komponentu obsługującego transakcje. To serializuje obiekt transakcji i powoduje eskalację, tak jak w przypadku transakcji serializowanej w domenie aplikacji. Jest rozprowadzany i lokalny Menedżer transakcji nie jest już odpowiedni.

Update 2:

Ponownie zbadane, osobiście, wszystkich wersji SQL Server - "Dev 3" faktycznie ma SQL2008, a "Dev 4" jest właściwie SQL2005. To nauczy mnie już nigdy nie ufać moim współpracownikom. ;) Z powodu tej zmiany danych, jestem prawie pewien, że znaleźliśmy nasz problem. Nasi programiści SQL2008 nie doświadczają problemu, ponieważ SQL2008 ma spore ilości niesamowite zawarte, że SQL2005 nie ma.

To również mówi mi, że ponieważ będziemy wspierać SQL2005, że nie możemy używać TransactionScope jak byliśmy, i jeśli chcemy używać TransactionScope będziemy musieli przekazać pojedynczy obiekt SqlConnection wokół...co wydaje się problematyczne w sytuacjach, gdy SqlConnection nie może być łatwo przekazane around...it po prostu pachnie instancją global - SqlConnection. Pew!

Update 3

Aby wyjaśnić tutaj w pytaniu:

SQL2008:

• pozwala na wiele połączeń w ramach jednego obszaru transakcyjnego (jak pokazano w powyższym przykładowym kodzie.)
• Zastrzeżenie # 1: Jeśli te wiele połączeń SQL jest zagnieżdżonych, to znaczy dwa lub więcej SqlConnections są otwierane w tym samym czasie, TransactionScope natychmiast eskaluje do DTC.
W przeciwieństwie do innych serwerów SQL, SQL connection może być używany jako serwer bazujący na SQL connection, który może być używany jako serwer bazujący na SQL connection.]}

SQL2005:

• nie pozwala na wiele połączeń w ramach jednej transakcji, kropka. Spowoduje to eskalację, gdy/jeśli zostanie otwarta druga sekcja SqlConnection.

Update 4

In zainteresowanie uczynieniem tego pytania jeszcze bardziej bałaganem użytecznym, i tylko dla większej jasności, oto jak możesz zmusić SQL2005 do eskalacji do DTC z pojedynczym SqlConnection:

using (TransactionScope transactionScope = new TransactionScope()) {
   using (SqlConnection connection = new SqlConnection(connectionString)) {
      connection.Open();
      connection.Close();
      connection.Open(); // escalates to DTC
   }
}

"Dlaczego tak się stało?" Cóż, jeśli użyjesz sqltableadapter przeciwko temu połączeniu przed jego otwarciem, sqltableadapter otworzy się i zamknij połączenie, skutecznie kończąc transakcję za Ciebie, ponieważ teraz nie możesz go ponownie otworzyć.

Tak więc, zasadniczo, aby z powodzeniem używać TransactionScope z sql2005, musisz mieć jakiś globalny obiekt połączenia, który pozostaje otwarty od momentu utworzenia pierwszej instancji TransactionScope, dopóki nie będzie już potrzebny. Poza zapachem kodu obiektu połączenia globalnego, otwarcie połączenia jako pierwsze i zamknięcie go jako ostatnie jest sprzeczne z logiką otwarcia połączenie tak późno, jak to możliwe i zamknięcie go tak szybko, jak to możliwe.