Shulou(Shulou.com)05/31 Report--

In this issue, the editor will bring you about how to thoroughly understand the distributed transaction XA model. The article is rich in content and analyzes and describes for you from a professional point of view. I hope you can get something after reading this article.

XA protocol is a distributed transaction processing specification proposed by X/Open organization, which mainly defines the interface between transaction manager TM and local resource manager RM. At present, mainstream databases, such as oracle and DB2, support XA protocol.

Mysql from version 5.0, the innoDB storage engine has supported the XA protocol, and today's source code introduces that the experimental environment uses a mysql database.

Two-phase submission

The two-phase commit of a distributed transaction divides the whole transaction commit into two phases: prepare and commit. Take the e-commerce system as an example, there are three services: order, account and inventory in the distributed system, as shown in the following figure:

In the first stage, the transaction coordinator sends a prepare request to the transaction participant. after receiving the request, if the transaction participant can commit the transaction, reply to yes, otherwise reply to no.

In the second stage, if all transaction participants reply to yes, the transaction coordinator sends a commit request to all transaction participants, otherwise sends an rollback request.

There are three problems with two-phase commit:

Synchronous blocking, local transactions lock resources during the prepare phase, and if there are other transactions to modify the xiaoming account, you must wait for the previous transaction to complete. This results in a decline in system performance.

If the prepare of the first phase is successful, but the second phase of the coordinator node is down before issuing the commit instruction, the data resources of all services are locked, and the transaction will wait indefinitely.

Data inconsistency, if the first phase of prepare is successful, but the second phase of the coordinator node fails to send commit commands to a node, it will lead to data inconsistency.

Three-stage submission

In order to solve the problem of two-phase submission, three-phase submission has been improved:

The timeout mechanism is introduced in both the coordinator node and the transaction participant.

The first phase of prepare is divided into two steps, canCommi and preCommit.

As shown below:

After the introduction of the preCommit phase, the orchestrating node checks the status of each transaction participant again before commit to ensure that their states are consistent. However, there is also a problem, that is, if a rollback request is issued in the third stage and some nodes do not receive it, the nodes that do not receive it will submit it after the timeout, resulting in data inconsistency.

Introduction to XA transaction syntax

The syntax for xa transactions is as follows:

The first phase of the three phases: enable the xa transaction, where xid is the global transaction id:

XA {START | BEGIN} xid [JOIN | RESUME]

End the xa transaction:

XA END xid [SUSPEND [FOR MIGRATE]]

The second of the three phases, namely prepare:

XA PREPARE xid

The third stage of the three stages, namely commit/rollback:

XA COMMIT xid [ONE PHASE] XA ROLLBACK xid

View all transactions in the PREPARE phase:

Introduction to XA RECOVER XA RECOVER [CONVERT XID] seata XA

Seata is an open source distributed transaction solution developed by Ali, which currently has four modes: AT, TCC, SAGA and XA.

The XA mode of seata is realized by using the database support for XA protocol in branch transactions. Let's take a look at the introduction on seata's official website: [1]

As you can see from the figure above, the flow of the seata XA pattern is the same as that of other patterns:

TM starts a global transaction

RM registers branch transactions with TC

RM reports branch transaction status to TC

TC sends a commit/rollback request to RM

TM ends a global transaction

Here is an introduction to the UML class diagram associated with RM client initialization: [2]

One of the classes in this figure is AbstractNettyRemotingClient, whose inner class, ClientHandler, handles the request from TC and delegates it to the processMessage method of the parent class AbstractNettyRemoting. The processMessage method calls the process method of the RmBranchCommitProcessor class.

It should be noted that "seata's xa mode optimizes the traditional three-phase commit to two-phase commit":

In the first stage, the three steps of opening XA, executing sql and ending XA are executed, and then XA prepare is executed directly.

The second phase is to execute XA commit/rollback.

Mysql currently supports two-phase optimization of the seata xa mode.

"but this optimization is not supported for oracle, because oracle implements the standard xa protocol, that is, after xa end, the coordinator node uniformly sends prepare to transaction participants, and finally sends commit/rollback. This also leads to poor support for oracle in seata's xa mode. "

Seata XA source code

The XA pattern in seata is implemented using the data source agent, which needs to be manually configured as follows:

Bean@ConfigurationProperties (prefix = "spring.datasource") public DruidDataSource druidDataSource () {return new DruidDataSource ();} @ Bean ("dataSourceProxy") public DataSource dataSource (DruidDataSource druidDataSource) {return new DataSourceProxyXA (druidDataSource);}

You can also create a XAConnection based on a normal DataSource, but this approach has compatibility issues (such as oracle), so seata uses the developer to configure XADataSource.

The XA data source agent provided by seata requires that druid connection pooling be used in the code framework.

1. The first stage of XA

When RM receives a DML request, seata will use ExecuteTemplateXA to execute it. A key part of the execution method execute is to change the autocommit attribute to false, while the default autocommit for mysql is true. After the transaction is committed, change the autocommit back to the default.

Let's take a look at the main code submitted in the first phase of XA.

1) enable XA

In the above code note [1], the setAutoCommit method of the ConnectionProxyXA class is called. In the source code of this method, XA start mainly does three things:

Register a branch transaction with TC

Call the XA Start of the data source

XaResource.start (this.xaBranchXid, XAResource.TMNOFLAGS)

Set xaActive to true

Instead of directly using the branchId returned by TC as the branchId of the xa data source, RM rebuilds one using global transactions id (xid) and branchId.

2) execute sql

Call the execute of PreparedStatementProxyXA to execute sql.

3) XA end/preparepublic void commit () throws SQLException {/ / omit part of the source code try {/ / XA End: Success xaResource.end (xaBranchXid, XAResource.TMSUCCESS); / / XA Prepare xaResource.prepare (xaBranchXid); / / Keep the Connection if necessary keepIfNecessary () Catch (XAException xe) {try {/ / Branch Report to TC: Failed DefaultResourceManager.get () .branchReport (BranchType.XA, xid, xaBranchXid.getBranchId (), BranchStatus.PhaseOne_Failed, null) } catch (TransactionException te) {/ / only one warn level log is printed here} throw new SQLException ("Failed to end (TMSUCCESS) / prepare xa branch on" + xid + "-" + xaBranchXid.getBranchId () + "since" + xe .getMessage (), xe);} finally {cleanXABranchContext ();}}

From this source code, we can see that commit does three main things:

Call the XA end of the data source

Call the XA prepare of the data source

Report branch transaction status to TC

At this point we can see that seata combines the first two phases of the xa protocol into one phase.

2. XA commit

The invocation relationship here is represented by a timing diagram:

Take a look at the process method of the RmBranchCommitProcessor class. The code is as follows:

@ Overridepublic void process (ChannelHandlerContext ctx, RpcMessage rpcMessage) throws Exception {String remoteAddress = NetUtil.toStringAddress (ctx.channel (). RemoteAddress ()); Object msg = rpcMessage.getBody (); if (LOGGER.isInfoEnabled ()) {LOGGER.info ("rm client handle branch commit process:" + msg);} handleBranchCommit (rpcMessage, remoteAddress, (BranchCommitRequest) msg);}

From the sequence diagram of the call relationship, you can see that the above handleBranchCommit method finally calls the handle method of AbstractRMHandler, and finally calls the finishBranch method of the ResourceManagerXA class through the branchCommit method. The ResourceManagerXA class is the resource manager of the XA schema. Take a look at the following class diagram, which is the UML class diagram of the resource manager (RM) in seata:

The above finishBranch method calls the connectionProxyXA.xaCommit method. Let's finally take a look at the xaCommit method:

Public void xaCommit (String xid, long branchId, String applicationData) throws XAException {XAXid xaXid = XAXidBuilder.build (xid, branchId); / / because mysql is used, where xaResource is MysqlXAConnection xaResource.commit (xaXid, false); releaseIfNecessary ();}

The commit method of the data source is called above, committing the RM branch transaction.

At this point, the entire RM branch transaction is over. The code logic of Rollback is similar to commit.

Finally, the xaResource above is an instance of the MysqlXAConnection class in the mysql-connector-java.jar package, which encapsulates the XA protocol interface provided by mysql.

The implementation of XA pattern in seata is accomplished by using data source agent, and the underlying layer uses the database's native support for XA protocol.

In the java driver library of mysql, the MysqlXAConnection class encapsulates the underlying interface of the XA protocol for external calls.

Compared with the TCC and SAGA patterns that need to implement prepare/commit/rollback logic in the business code, the XA pattern does not invade the business code.

The above is the editor for you to share how to thoroughly understand the distributed transaction XA model, if you happen to have similar doubts, you might as well refer to the above analysis to understand. If you want to know more about it, you are welcome to follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.