[Source] .net/C# Distributed TransactionScope

To quote someone else's guide:
In actual development work, execute an event, and then call another interface to insert data, if there is an exception in the processing logic, then the previously inserted data will become junk data,
What we want is to be able to define the entire method as a transaction, and the TransactionScope class provides a simple method that allows you to not have to interact with the transaction itself.
to mark a block of code as participating in a transaction. The TransactionScope object creates a transaction and sets the transaction to the Current property of the Transaction class.

1. Advantages of TransactionScope
1. It is more convenient to use. TransactionScope can implement implicit transactions, so that you can write data access layer code without considering transactions, but control transactions at the business layer.
2. Distributed transactions can be implemented, such as cross-database or MSMQ.

2. Disadvantages of TransactionScope
1. The cost performance is not high. For example, you only control the transactions of a library in "Scope". Using "TransactionScope" is a bit wasteful.
2. Under normal circumstances, as long as you use "TransactionScope", you need to configure MSDTC, install a firewall, and open port 139. This port cannot be changed

3. If you have to use distributed transactions, you have to think about it
1. Does this operation have to be in the transaction? If this step is not completed or fails, is it worth rolling back the entire transaction? Is there no elegant compensation or fault tolerance measures?
2. How many points do distributed transactions involve? Must have a large string of real-time operations? Can't you streamline some points through notification operations?
3. After initiating a distributed transaction, did you perform transaction-agnostic operations, even though these operations were non-transaction-related? (e.g., reading data, calculating, waiting for the user to return a message, waiting for the call return of other modules, etc.)
4. You didn't count some reading operations in the transaction, did you? This is an easy mistake to make when you enlist a select operation in the transaction.
5. Some steps of your operation can be executed after all operations are completed. This type of operation has obvious notification characteristics. Notification operations say, I give you a notification, and I guarantee that the notification will reach you;
You must take this notice and ensure that it is processed, but you do not have to deal with it as soon as I notify you. This operation can obviously be done with another task.

4. Pay attention to the following points when using distributed transactions
1: Make sure that the machine participating in the transaction has enabled distributed transaction support.
2: If the machine has the firewall turned on, you need to set the msdtc process as an exception.
3: The machine participating in the transaction cannot cross the domain (if it is cross-domain, Microsoft does not have an exact solution at present);
4: Use distributed transactions only when you have multiple databases, if it is the same database, it is best to use SqlTransaction.