Summary of Java Distributed transactions

Distributed transaction processing (Distributed Transaction processing, DTP) involves multiple databases that are distributed in different places, but the operation of the database must be committed or rolled back. Whenever any database operation fails, all databases participating in the transaction need to be rolled back.

For example, the A service is deployed on Tomcat, executes insert a and invokes the B and C interfaces, b services are deployed on WebLogic, insert B is executed, the C service is deployed in Nginx, and insert C is executed. Now to execute a, and the update fails when it executes to insert C, the requirement of the distributed transaction is that insert a and insert B be transacted for rollback.

To handle distributed transactions in Java, you need to use JTA. JTA requires a Web server for support. (Add one point: Why the Web server has open source charges, there are good and bad, the most important of which is the ability to deal with the transaction, open-source Java EE Server at this point with WebLogic, WebSphere and other commercial application server can not be compared. ）

Open organization-defined Distributed transaction processing model X/open DTP Model (1994) includes application (AP), transaction manager (TM), Resource Manager (RM, database), Communications Resource Manager (CRM) four. XA is an interface specification (that is, an interface function) between the transaction manager and the database defined by the X/open DTP, which notifies the start, end, and commit, rollback, etc. of a database transaction.

The XA interface specification uses the two-phase commit protocol (2-PC protocol) to complete a global transaction to ensure that all databases in the same transaction are successfully or rolled back at the same time.
The two-phase commit protocol assumes that there is a write-ahead log for each database point, and each write request is a log before the write is actually executed.

A two-phase submission requires an intermediary coordinator. Only JTA in Java can support two-phase commits, and this intermediate coordinator is the EE application server.

Two stages:

1, the preparation stage. After the execution of the INSERT, the Java EE Application Server receives the commit instruction and notifies the database to prepare for the transaction submission. After the database receives the response, prepares the work, basically is a pre-commit work, if can submit responds the Java EE Application Server to be able to commit successfully, if cannot commit the response the Java application Server is unable to commit.

2, the Java EE application Server after the collection of all the responses to judge, if the information received in the first phase can be submitted, then notify all databases to submit; If one of the information received in the first phase is not committed, then all databases are notified of rollback operations.

The following version of the description goes from WDWBW ' s blog:

The first stage is the commit request phase (Commit-request phase):
1. The transaction manager sends a query to commit message request to all databases and then begins to wait for a response;
2. If the database can commit its own branch of the transaction, it will record the operations it has done in that branch of the transaction (each entry in undo log and redo log);
3. The database responds to the consent of the submitted response.
The second stage is the commit phase (commit phase):
If all the responses received by the transaction manager are agreement,
1. The transaction manager logs and sends a commit message request to all databases;
2. Perform operations on each database, releasing all locks and resources related to the transaction;
3. Each database responds to the transaction manager;
4. When all replies are received, the transaction manager ends the current transaction

If any of the responses received by the transaction manager are abort,
1. Transaction manager logs and sends rollback message requests to all databases;
2. Each database performs an undo operation to release all locks and resources related to the transaction;
3. Each database responds to the transaction manager;
4. When all replies are received, the transaction manager ends the current transaction

Other: Processing of pending transactions: After the first phase is completed, the contributor server goes down, resulting in a request to not receive a second-phase commit or ROLLBACK transaction. At this point, the participant's local transaction is in a pending state (IN-DOUBT). Distributed transactions handle pending transactions using the following mechanism: When restarted, for all pending transactions on this machine, the participant sends a query request to the superior to get the final result (commit or abort) of each transaction, and he gets a definite reply to commit or rollback the local transaction.

　　

Summary of Java Distributed transactions