.Net distributed transaction deadlock phenomenon and solution

In this article, I will introduce the .Net distributed transaction deadlock phenomenon encountered once and the solution. We will first understand the composition of the transaction framework, then analyze the code that causes the deadlock, and finally propose a solution.

transaction framework

The development framework JMSFramework divides distributed transactions into four stages, namely: execution, confirmation, submission and retry.

1. Execution
Call microservices to perform related business operations. If any one of these service executions throws an exception or crashes, all transactions are rolled back.

2. Confirmation
In this stage, a confirmation request will be sent to each microservice. The main purpose is to verify whether the current network is normal and whether the microservice is down. If there is any abnormality in this stage, all transactions will be rolled back.

3. Submit
First, JMSFramework will notify the gateway to mark the distributed transaction as successful. (If the notification gateway fails, all transactions will be rolled back) Then
notify each microservice to commit the transaction to ensure that all operations have been completed.
If a service fails to commit a transaction, it will not affect other services to commit transactions.

4. Retry
There is a very small chance that the execution will reach this stage.
When a microservice unexpectedly goes down when the transaction is actually committed, the transaction is not successfully committed. Once the server restarts, it consults the gateway and learns that the transaction has been marked as successful. At this time, the system will automatically re-execute the relevant business code and submit the transaction to ensure data consistency.

deadlocked code

Next, let's look at the code that triggers the deadlock:

            using ( var client = new RemoteClient(gatewayAddrs))
            {
                //标识后面的调用需要启用分布式事务控制
                client.BeginTransaction();