TransactionScope: Czy stało się lepsze?

Question

Kiedy TransactionScope po raz pierwszy wyszedł, natknąłem się na poważne problemy z uruchomieniem go między moją maszyną wirtualną (XP) a naszym serwerem bazy danych (Windows Server 2003).

Kiedy zagłębiłem się w coś więcej, wydawało mi się, że to trudny i powszechny problem, który miał szansę stać się bólem głowy w produkcji, więc postanowiłem nie obsługiwać transakcji w ten sposób (mimo że bardzo lubię składnię i Naprawdę chciałem, żeby działało).

Czy te problemy są nadal dostępne lub czy można z nich bezpiecznie korzystać? Czy używasz tego regularnie teraz bez problemów?

Wielkie dzięki!

Uwaga: Minęło dużo czasu, ale myślę, że problem miał coś wspólnego z Distribute Transaction Coordinator. Długo się z nim bawiłem i nigdy nie mogłem go uruchomić.

Answer 1

Rick Strahl ma świetny post o zakresie transakcji i LINQ do SQL here. Jego kontekst jest bardziej LINQ do SQL, ale myślę, że istnieją pewne zasady, które mogą pomóc w rozwiązaniu twojego pytania.

EDIT: aby dokładniej odpowiedzieć na pytanie, oto co Strahl ma do powiedzenia o TransactionScope:

Tradycyjnie TransactionScope był otoki .NET wokół Distributed Transaction Coordinator (DTC), ale jego funkcjonalność rozszerzył nieco. Jedną z obaw jest to, że DTC jest dość drogi pod względem wykorzystania zasobów i wymaga, aby usługa DTC faktycznie działała na komputerze (kolejna usługa, która jest szczególnie kłopotliwa w przypadku instalacji klienta).

Jednak najnowsze aktualizacje sterowników klienta TransactionScope i SQL Server umożliwiają korzystanie z klasy TransactionScope i łatwość obsługi, jaką zapewnia, bez wymagania kodu DTC, dopóki działa się w pojedynczej bazie danych i jednym spójnym ciągiem połączenia.

Answer 2

Używam TransactionScope od ponad roku teraz bez żadnych problemów. Jednak aplikacja jest wewnętrzną aplikacją z bardzo małą liczbą użytkowników. Ponadto baza danych i aplikacja znajdują się na tym samym serwerze.

Oto kilka informacji na TransactionScope i gdzie szukać więcej informacji: Ilekroć utworzyć obiekt TransactionScope zaczyna lekką transakcję. Dopóki używasz pojedynczego połączenia/zasobu obsługującego transakcje lekkie, transakcja będzie obsługiwana przez menedżera zasobów zużywającego jak najmniej zasobów przy bardzo dobrej wydajności. Po dodaniu drugiego połączenia/zasobu do zakresu transakcji menedżer transakcji zostanie automatycznie awansowany do menedżera transakcji OleTx, który może obsługiwać transakcje rozproszone przy użyciu technologii DTC COM +. Będzie to również miało miejsce w przypadku pojedynczego połączenia z menedżerem zasobów, który nie obsługuje transakcji o małej masie, takich jak SQL Server 7/2000, Oracle i inne RDBMS.

Oto dwa zasoby, które mogą być w stanie pomóc:

„Microsoft Windows Server 2003 z dodatkiem Service Pack 1 (SP1) i Windows XP z dodatkiem Service Pack 2 (SP2) zawiera wiele nowości i zmiany związane z zabezpieczeniami Niektóre z tych zmian dotyczą usługi Microsoft Distributed Transaction Coordinator (MSDTC)." New functionality in the Distributed Transaction Coordinator service in Windows Server 2003 Service Pack 1 and in Windows XP Service Pack 2

i

whitepaper

Juval Lowy w sprawie System.Transactions. Introducing System.Transactions in the Microsoft .NET Framework version 2.0

Answer 3

Są jeszcze kwestie dotyczące TransactionScope W moim bieżącego projektu jesteśmy w nieregularnych odstępach czasu działa w obie„Nie można zaciągnąć się wyjątki transakcji i wyjątek wyjątku TransactionInDoubtException Oba wyjątki związane z TransactionScope Jednym z obejść dla obu wyjątków jest użycie pojedynczego połączenia Oracle (jeśli dotyczy oczywiście). Przeczytaj o tym w: Avoid unwanted Escalation to Distributed Transactions

Aby uzyskać informacje na temat wpływu na wydajność, przeczytaj mój wpis: Performance impact using TransactionScope