LCN distributed transaction system realizes unified control of transactions through proxy data resources and TxManager(transaction manager) coordination. Such control mode makes the framework have very low business embeddedness. In addition to local proxy resources, it also prevents access by others through exclusive lock, thus ensuring the isolation of transactions.

Step introduction: Step 1: The transaction initiator will call TM notification to create a transaction before starting to execute the business. The transaction contains key transaction information, such as node information and global transaction Id identifier, etc. The initiator will wait for TM response data before performing Step 2. Step 2: After receiving the transaction message created by TM, the transaction initiator will start to execute its own business code. In the process of executing business, it will start to call each participant and transfer the transaction identifier information created by TM to the participant. Step 3: The transaction initiator initiates a call to the transaction participant, which passes transaction flag information to the participant. Step 4: When the participant receives the request from the initiator, the local business is executed. The local transaction will not be processed immediately after the transaction is completed. In fact, the connection object is brokered in the system without the real transaction operation on it. Step 5: After party A completes the execution of the local business, it requests TM to join the transaction. The main information submitted includes the local log information and node information. Before requesting TM, the timeout waiting task will be enabled first, and then the instruction to join the transaction will be initiated to TM. Steps 6, 7, 8: This step is the same as reconciliation 3, 4, and 5, but the participants are different. Step 9: After the initiator completes all the participant calls, it will notify TM to commit the transaction according to the final transaction status. This step needs to confirm THAT TM has received the message. The committed transactions are classified into commit and ROLLBACK. The process of TM notification is to notify and confirm all participants step by step, and then notify the initiator step 10: TM notifying the participant node to commit or rollback the transaction. The principle for the success of TM notification is to notify the participant of the message, and the participant will feedback the message to TM after completing the transaction. TM will call the transaction notification of the next participant after receiving the message. There are timeout mechanism, retry mechanism and switching module transaction mechanism. For details, please refer to the following content. Step 11: The principle of this step is the same as step 10, but the participants are different. Step 12: Notify the initiator of the transaction. This step is to notify the initiator of the operation steps of the transaction submission after TM has completed the notification confirmation of all participants, and the initiator completes the operation of the transaction according to the transaction status. Step 13: When the initiator completes the transaction operation, it will notify TM that the transaction has been committed. At this time, all transactions are completed for TM. The message does not need to be received by TM, and the response data will be sent to the caller after the completion of sending. TM will initiate the request again because the transaction has been committed and cannot commit again because the SQL log has been cleaned.

Steps:

Business method (start transaction)

To start a transaction, the participant or initiator starts a transaction when performing its own services. For JDBC, the participant or initiator needs to obtain a Connection object. In this step, the participant accesses the JDBC interface to obtain a Connection object.

JDBC operations (getting connections)

This represents a request to get a Connection object from the Connection pool using the JDBC protocol.

LCN Proxy connection pool (get connections)

This refers to the continuation of the request through the LCN proxy Connection pool, fetching the Connection object to the database Connection pool layer.

Database connection pool (get connections)

This is where the database connection pool continues to get the connection request passed to the database layer.

LCN Proxy connection Pool (Proxy connection)

A proxy connection means that LCN creates a proxy object from the returned connection object and then returns it to the caller. Proxy objects are mainly for fetching

To the “pseudo-commit” proxy controlling party that actually performs the business operations and controls the data, here is an abstract interface that currently represents the relationship

A proxy implementation of a database.

Business method (Performing business)

The business method performs operations on the resource while performing the business, and sends data to the object of the LCN agent when the resource is operated on.

Business methods (Business operations)

As the business operates, the control data is passed to the LCN proxy connection pool.

LCN proxy connection pool (parses executed SQL and saves it) LCN receives the operation of the business method and performs business parsing on it. In this case, since it is a relational database, the parsed result will be AN SQL statement. There are two main considerations for SQL: 1. All assignment objects will be assigned by Java instead of directly using database functions, like mysql’s now() function, and then compensating them

In case, the recorded time will be inconsistent with the actual time, which violates the idempotence; 2, if the insert statement is a database primary key increment type, you need to obtain the primary key information after the insert.

Business method (Commit transaction)

The business method completes all business operations and begins to initiate a transaction commit request to commit locally. LCN proxy connection pool (transaction submitted false, start timeout mechanism) LCN proxy connection object accept to commit the transaction request will stop the transaction, but will parse to the business operations of log data stored locally (SQL), opened the countdown waiting for news of the TM notice again, and then return to submit success to business method.

LCN Proxy connection pool (response submission)

The LCN proxy connection pool will respond to the commit transaction and send the result back to the participating business party, and the business method will continue to execute the business and transfer the data

Feedback to the caller.

TxManager(Notification Transactions)

When receiving transaction notification from TM, the corresponding transaction operation will be performed according to the transaction state.

LCN Proxy connection pool (Commit transaction)

When a transaction is committed, the TC will first create a deletion of the operation log step, which corresponds to a relational database

Add the operation procedure to the local transaction to be committed, and then commit it together with the local transaction. When a rollback is received, the delete operation is added to the transaction and rolled back with it, mainly so that the delete log operation is processed with the local transaction when the transaction is rolled back or committed. Note: When the DELETE statement is executed, the system determines whether the execution is successful according to the number of logged logs. If the execution is not successful, the number of affected rows must be different because the log data is not saved successfully. In this case, the system continues to save logs. There is also no double commit problem when a transaction is committed or rolled back, because the execution log of a double commit is cleaned up at the time of the transaction commit and local business log data is retained only when compensation is required. If the transaction cannot be submitted after the retry, it will be directly regarded as the compensation situation. At this time, the TM transaction will be returned to the compensation state, and the local timeout task will be cancelled.

LCN Proxy connection pool (response transaction)

After the LCN transaction is committed, it responds to the transaction notification to TM, notifying TM that the transaction has been completed.

LCN Proxy connection pool (Query transaction group)

If TM does not request to the LCN agent connection pool for a long time, then the LCN agent connection pool will trigger the timeout request mechanism and will be active

To contact the TM, if can’t access the TM, will try again to access the request once again, if still cannot access will be according to the cluster deployment characteristics of TM, request other nodes of the TM, if all can’t access, can only be TM failure or network failure, these circumstances LCN proxy connection will roll back the transaction, but do not delete the log data. When TM is contacted again, the log data request status can be detected and then transaction commit or rollback request can be made. If TM can be contacted, TM will respond with a message to continue waiting, and TC will continue to wait for TM notification. Therefore, the TC’s wait timeout can be set to be short, since TM will inform TC to continue to wait whenever it is asked about pending transactions or transactions that have not been notified. When the TM state requested by TC is already in the compensation state, it will wake up TM’s continue request instruction, and then TC will continue to enter the timing wait state.

LCN agent connection pool (transaction rollback, resource release, start timing)

When the ontology transaction is submitted, the global lock of data exclusivity will be obtained through TM first, and then the rollback operation of the local transaction will be performed.

It then starts the log SQL store commit in the local transaction and then performs the scheduled task timing.

LCN Proxy connection pool (Commit transaction)

After TM notifies the transaction, the commit of the local transaction will be executed. The commit of the local transaction will query the EXECUTED SQL and then execute the transaction

Execute the insert SQL and delete log SQL together in the same transaction. If the rollback operation, it is directly delete the execution of SQL, this is only the difference with strong consistent, other operations can refer to the strong consistent transaction process.

Welcome to follow my wechat official account [Village of the Apes]

To talk about Java interview and my wechat further communication and learning, wechat mobile search [codeYuanzhicunup] can be added if there are related technical problems welcome to leave a message to discuss, the public number is mainly used for technology sharing, including often meet test analysis, as well as source code interpretation, micro service framework, technical hot spots, etc..