table of Contents
1. Introduction
LCN does not produce transactions, LCN is just a coordinator of local transactions;
LCN name abbreviations: lock transaction unit (lock), confirm transaction module status (confirm), notify transaction (notify)
Second, the principle of execution
As shown in the figure, microservice A, microservice B, and TxManager transaction coordinator all need to register services in Eureka; Eureka is used for mutual service discovery between TxManager and other services; redis is used to store the information of our transaction group and Compensation information; both microservice A and microservice B need to configure the package architecture of my TxClient
Three, implementation steps
3.1, create a transaction group
The transaction group means that we store the transaction information of each node (microservice) unit in a fixed unit during the entire transaction process. But this information does not represent transaction information, but only serves as a module's marking information.
Creating a transaction group refers to the process of calling TxManager to create a transaction group object before the transaction initiator starts to execute the business code, and then getting the transaction identifier GroupId.
3.2, add transaction group
Adding a transaction group refers to the operation of adding and notifying TxManager of the transaction information of the module after the participants have finished executing the business method
3.3, close the transaction group
Refers to the action of notifying the initiator of the execution result status to the TxManager after the initiator finishes executing the business code. After the method of closing the transaction group is executed, TxManager will notify the corresponding participating modules to commit or roll back the transaction according to the transaction group information
3.4, execution flow chart
4. Affairs coordination mechanism
As shown in the figure: Assuming that the service has been executed to the process of closing the transaction group, then it will be notified to TxManager as a module and then tell him that the transaction has been completed. Then the next action of Txmanager in the figure is to obtain the transaction information of this transaction group through the id of the transaction group; then check which modules are involved in the corresponding, and then if there are three modules of A/B/C; then Correspondingly, notify, submit, and roll back the three modules.
Who did you submit to when submitting?
Submitted to the TxClient module. Then there is a connection pool under the TxCliient module, which is a connection pool customized by the framework (as shown in the DB connection pool); this connection pool actually holds the connection resources of this transaction before the transaction is notified, but it is not released. But he executed the close method in the aspect. When executing close. If necessary (TxManager) the connection of the distributed transaction framework. It is called a "false shutdown", that is, it did not shut down, but executed the shutdown method once. The actual resources are not released. This resource is held in the connection pool of LCN;
what about when TxManager notifies commit or transaction rollback?
TxManager will notify our TxClient. Then TxClient will perform the corresponding commit or rollback. Close the connection after submitting or rolling back. This is the transaction coordination mechanism of LCN. To put it bluntly, it is the mechanism of proxy DataSource; it is equivalent to intercepting the connection pool and controlling the transaction commit of the connection pool.
5. Transaction compensation mechanism
5.1. What is the compensation transaction mechanism
The principle of LCN's compensation transaction is to simulate the request of the last failed transaction, and then pass it to the TxClient module and then execute the requested transaction again;
simply put: lcn transaction compensation refers to when the txManager cannot notify the transaction unit in the case of service hang-up and network jitter . (There are two reasons why the service is down and the network is faulty.) In this case, TxManager will make a mark; and then return to the initiator. Tell him that there are any circumstances that have not been notified of this matter.
Then, after receiving this information, the initiator will make a mark to indicate that this transaction requires compensation. This is the transaction compensation mechanism.
5.2. Why is transaction compensation needed?
Transaction compensation means that when a certain business method is executed, the transaction is not submitted normally due to problems such as server hang-up or network jitter that should be executed successfully. In this scenario, compensation is required to complete the transaction to achieve transaction consistency ；
5.3. Triggering conditions of compensation mechanism
When the step of closing the transaction group is executed, if the initiator accepts the failed state, the transaction will be recognized as a transaction to be compensated, and then the initiator will asynchronously notify the TxManager of the transaction data. After receiving the compensation transaction, TxManager first notifies the compensation callback address, and then compensates or saves the transaction data of this aspect according to whether the automatic compensation transaction status is turned on;