[Kilde] .net/C# Distribueret TransaktionScope

For at citere en andens guide:
I selve udviklingsarbejdet skal man køre en begivenhed, og derefter kalde et andet interface for at indsætte data; hvis der er en undtagelse i behandlingslogikken, vil de tidligere indsatte data blive junk-data,
Det vi ønsker, er at kunne definere hele metoden som en transaktion, og TransactionScope-klassen tilbyder en simpel metode, der gør, at du ikke behøver at interagere med selve transaktionen.
at markere en kodeblok som deltagende i en transaktion. Objektet TransactionScope opretter en transaktion og sætter transaktionen til Current-egenskaben for Transaction-klassen.

1. Fordele ved TransactionScope
1. Det er mere bekvemt at bruge. TransactionScope kan implementere implicitte transaktioner, så du kan skrive dataadgangslagkode uden at tage hensyn til transaktioner, men kontrollere transaktioner på forretningslaget.
2. Distribuerede transaktioner kan implementeres, såsom tværdatabase- eller MSMQ-transaktioner.

2. Ulemper ved TransactionScope
1. Omkostningspræstationen er ikke høj. For eksempel kontrollerer du kun transaktionerne i et bibliotek i "Scope". At bruge "TransactionScope" er lidt spild.
2. Under normale omstændigheder, så længe du bruger "TransactionScope", skal du konfigurere MSDTC, installere en firewall og åbne port 139. Denne port kan ikke ændres

3. Hvis du skal bruge distribuerede transaktioner, skal du tænke over det
1. Skal denne operation være en del af transaktionen? Hvis dette trin ikke bliver fuldført eller fejler, er det så værd at rulle hele transaktionen tilbage? Findes der ikke elegante kompensations- eller fejltoleranceforanstaltninger?
2. Hvor mange punkter involverer distribuerede transaktioner? Skal der være en lang række realtidsoperationer? Kan du ikke strømline nogle punkter gennem notifikationsoperationer?
3. Efter at have startet en distribueret transaktion, udførte du transaktions-agnostiske operationer, selvom disse operationer ikke var transaktionsrelaterede? (f.eks. læsning af data, beregning, venting på, at brugeren returnerer en besked, venting på opkaldsretur af andre moduler osv.)
4. Du talte vel ikke nogle læseoperationer med i transaktionen, vel? Dette er en nem fejl at begå, når du indsætter en select-operation i transaktionen.
5. Nogle trin i din operation kan udføres efter alle operationer er afsluttet. Denne type operation har tydelige notifikationskarakteristika. Notifikationsoperationer siger, jeg giver dig en notifikation, og jeg garanterer, at notifikationen når dig;
Du skal tage imod denne meddelelse og sikre, at den bliver behandlet, men du behøver ikke håndtere den, så snart jeg giver dig besked. Denne operation kan selvfølgelig udføres med en anden opgave.

4. Vær opmærksom på følgende punkter, når du bruger distribuerede transaktioner
1: Sørg for, at maskinen, der deltager i transaktionen, har aktiveret distribueret transaktionsunderstøttelse.
2: Hvis maskinen har firewallen slået til, skal du sætte msdtc-processen som en undtagelse.
3: Maskinen, der deltager i transaktionen, kan ikke krydse domænet (hvis det er på tværs af domæner, har Microsoft ikke en præcis løsning på nuværende tidspunkt);
4: Brug kun distribuerede transaktioner, når du har flere databaser; hvis det er den samme database, er det bedst at bruge SqlTransaction.