Thank you for your continuous attention. Today, the XA model of distributed transaction “Solomon” can be followed by my wechat public account “Solomon”.

XA concept

The XA specification is a Distributed Transaction Processing (DTP) standard defined by the X/Open organization.

The XA specification describes the interface between a global transaction manager and a local resource manager. The purpose of the XA specification is to allow multiple resources (such as databases, application servers, message queues, and so on) to be accessed in the same transaction so that ACID properties remain valid across applications.

The XA specification uses two-phase Commit (2PC, two-phase Commit) to guarantee that all resources Commit or roll back any particular transaction at the same time.

The XA specification was first proposed in the early 1990s. Currently, almost all major databases provide support for the XA specification.

Seata transaction schema definition

Seata defines the framework for global transactions.

A global transaction is defined as the overall coordination of several branch transactions:

TM initiates (Begin), commits (Commit), and rolls back (Rollback) global transactions to TC requests.

TM binds the XID representing the global transaction to the branch transaction.

RM registers with the TC to associate the branch transaction with the global transaction represented by the XID. RM reports the branch transaction execution result to the TC. (Optional) The TC sends the Branch Commit or Branch Rollback commands to THE RM.

Seata’s global transaction process is divided into two phases:

  • Execution phase: Execute branch transactions and ensure that the execution results are Rollbackable and Durable.
  • Completion phase: According to the resolution formed in the execution phase, apply the global Commit or Rollback request sent by TM to TC, and TC command RM drives the branch transaction to Commit or Rollback.

The so-called transaction mode of Seata refers to the behavior mode of branch transactions running under the GLOBAL transaction framework of Seata. To be precise, it should be called the branch transaction pattern.

Different transaction modes differ in that branch transactions use different ways to achieve the goals of the two phases of the global transaction. That is, answer the following two questions:

  • Execution phase: How to implement the services and ensure that the results are Durable and Rollbackable.
  • Completion phase: How to commit or roll back the branch after receiving TC’s command?

Take our Seata AT mode and TCC mode as an example to understand:

Seata supports XA targets

Why add XA mode to Seata? What’s the point of XA support?

Problems with compensating transaction patterns

Essentially, the three transaction modes already supported by Seata: AT, TCC, and Saga are compensatory.

Compensatory transaction processing mechanisms are built on transaction resources (either at the middleware level or at the application level) that are themselves unaware of distributed transactions.

There is a fundamental problem with transactional resources being unaware of distributed transactions: true global consistency cannot be achieved.

For example, an inventory record, in the middle of a compensation transaction, is deducted from 100 to 50. At this point, the warehouse administrator connects to the database, queries the statistical inventory, and sees the current 50. Later, the inventory is compensated to roll back to 100 due to the transaction’s foreign rollback. Obviously, the warehouse administrator query counts 50 as dirty data.

It can be seen that compensating distributed transaction mechanism cannot guarantee data consistency from the global perspective outside the transaction framework because it does not require the mechanism of transaction resource itself (such as database) to participate.

The value of the XA

Unlike compensation, the XA protocol requires transaction resources themselves to provide support for specifications and protocols.

Because transaction resources are aware of and participate in distributed transaction processing, transaction resources (such as databases) can ensure effective isolation of data access from any perspective and meet global data consistency.

For example, in the inventory update scenario mentioned in the previous section, the intermediate data inventory 50 is guaranteed by the database itself and is not visible by the warehouse administrator’s query statistics during an XA transaction. (Of course the isolation level needs to read submitted above)

In addition to the fundamental value of global consistency, there are several benefits to supporting XA:

  1. Business invasiveness: Like AT, the XA pattern will be business invasiveness with no additional burden on application design and development.
  2. Extensive database support: THE XA protocol is widely supported by mainstream relational databases and requires no additional adaptation.
  3. Multilanguage support is easy: XA mode requires less of Seata’s RM because SQL parsing is not involved, and developing SDKS for different languages is thinner and easier than AT mode.
  4. Migration of traditional XA-BASED applications: Traditional, XA-BASED applications are migrated to the Seata platform to be smoother using XA mode.

XA is widely questioned

There is no single distributed transaction mechanism that can perfectly adapt to all scenarios and meet all requirements.

The XA specification was proposed in the early 1990s to solve the problem of distributed transaction processing.

Now, whether AT mode, TCC mode or Saga mode, these modes are proposed, in essence, from the XA specification of certain scenarios can not meet the requirements.

How do we think about the widely questioned issues with distributed transaction processing as defined by the XA specification?

Data locking:

Data is locked until the end of the transaction, and reads and writes are constrained by isolation levels.

Think about:

Data locking is the price you pay for greater isolation and global consistency.

A compensatory transaction mechanism that commits branch (local) transactions at execution time without locking data (resource level). And that comes at the expense of isolation.

In addition, AT mode uses global lock to ensure basic write isolation. In fact, data is locked, but the lock is centrally managed on the TC side, with high unlocking efficiency and no blocking problem.

Agreement blocking

After XA prepare, the branch transaction enters the blocking phase and must be blocked until XA COMMIT or XA ROLLBACK is received.

Think about:

The blocking mechanism of the protocol itself is not the problem. The key problem is that protocol blocking meets data locking.

If a resource participating in a global transaction is “disconnected” (does not receive a branch transaction termination command), the data it locks will remain locked. In turn, deadlocks can even occur.

This is the core pain point of XA protocol and the key problem that Seata introduced XA mode to solve.

The basic idea is two aspects: avoid “lost contact” and increase “self-unlock” mechanism. (There are a lot of technical details involved here, which will be discussed in the future evolution of XA mode.)

Performance is poor

The performance loss mainly comes from two aspects: on the one hand, the transaction coordination process, increasing the RT of a single transaction; On the other hand, lock conflicts for concurrent transaction data reduce throughput.

Think about:

There is no doubt that performance will decline compared to running scenarios without distributed transaction support.

In essence, the transaction mechanism (whether local or distributed) is a partial performance sacrifice for the simplicity of the programming model.

Comparison with the NON-invasive AT mode of the same business:

First, because the XA pattern also runs under the distributed transaction framework defined by Seata, it does not incur the communication overhead of more transaction coordination.

Second, lock conflicts occur between concurrent transactions if data is hot, which also exists in AT mode (global lock is used by default).

Therefore, XA mode is not significantly inferior to AT mode in two major areas that affect performance.

The performance advantages of AT mode are as follows: Centralized management of global data locks, lock release does not require THE participation of RM, lock release is very fast; In addition, for globally committed transactions, the completion phase is asynchronous.

XA mode for Seata

XA mode:

In the distributed transaction framework defined by Seata, using transaction resources (database, message service, etc.) to support XA protocol, a transaction mode to manage branch transactions by XA protocol mechanism.

  • Execution stage:
    • Rollback: Business SQL operations are placed in XA branches and rollback is guaranteed by resource support for the XA protocol
    • Persistence: After the XA branch is complete, XA prepare is executed, again guaranteed by resource support for the XA protocol (that is, any subsequent accidents do not result in a rollback failure)
  • Completion stage:
    • Branch commit: Perform a COMMIT for the XA branch
    • Branch rollback: Perform rollback on the XA branch

How is XA pattern implemented and used

XA mode design

Design goals

The basic design goals of XA pattern are two main aspects:

  1. In terms of scenarios, global consistency is required.
  2. From the application, keep the same as AT mode without intrusion.
  3. From the mechanism, it ADAPTS to the characteristics of distributed micro-service architecture.

Overall idea:

  1. Same as AT pattern: Branch transactions built into XA pattern AT the granularity of local transactions in the application.
  2. The XA programming model is made transparent by wrapping the interaction mechanism of XA protocol at the framework level outside the scope of application local transactions through data source agent.
  3. The 2PC of XA was disassembled and XA prepare was performed at the end of the execution stage of the branch transaction. XA protocol was perfectly integrated into the transaction framework of Seata to reduce a round of RPC interaction.

The core design

Overall operation mechanism

The XA pattern runs within the transaction framework defined by Seata:

  • Execution phase (E xecute) :
    • XA Start /XA End /XA Prepare + SQL + Register branches
  • Completion stage (F inish) :
    • XA commit/XA rollback

Data source agent

XA mode requires XAConnection. You can obtain XAConnection in two ways:

  • Option 1: Ask developers to configure XADataSource
  • Method 2: Create from the developer’s common DataSource

The first way is to impose a cognitive burden on the developer by learning and using XA data sources specifically for the XA schema, which is contrary to the design goal of a transparent XA programming model.

The second approach is more developer-friendly and, like the AT model, developers don’t have to worry about any issues AT the XA level AT all and just keep the native programming model.

The second approach is designed to be implemented first: the data source agent creates the corresponding XAConnection based on the normal JDBC connection obtained from the normal data source.

The data source proxy mechanism of the AT mode is as follows:

However, the second approach has limitations: there is no guarantee of compatibility correctness.

In effect, this approach does what database drivers do. Different vendor versions of database driver implementation mechanisms are vendor proprietary, we can only ensure that fully tested drivers are correct, developers using different driver versions may cause mechanism failure.

This is evident in Oracle

Taken together, the data source proxy design in XA mode needs to support both the first approach: proxy based on XA data sources.

The data source proxy mechanism of the AT mode is as follows:

The branch register

XA start requires the Xid parameter.

This Xid needs to be associated with the Xid and BranchId of the Seata global transaction in order to be committed or rolled back by the TC-driven XA branch.

Currently, Seata BranchId is uniformly generated by TC in the branch registration process, so the timing of XA mode branch registration needs to be before XA start.

A possible optimization direction for the future:

Delay branch registration as long as possible. Similar to AT mode, branches are registered before local transactions are committed to avoid meaningless branch registration in case of branch execution failure.

This optimization direction needs the change of BranchId generation mechanism to match. The BranchId is not generated through the branch registration process, but is generated and then the branch is registered with the BranchId.

summary

Here are just a few important core designs to illustrate the basic workings of the XA pattern.

In addition, there are also important aspects including connection retention, exception handling, etc., you can learn more from the project code.

I will write it and communicate with you one after another.

Use of XA mode

In terms of programming model, XA mode is exactly the same as AT mode.

For example, see SEATA-XA on the Seata website

The sample scenario is a classic Seata commodity ordering business involving inventory, order and account.

In the sample, the upper programming model is identical to the AT pattern. The switch between XA mode and AT mode can be realized only by modifying the data source agent.

@Bean("dataSource")
    public DataSource dataSource(DruidDataSource druidDataSource) {
        // DataSourceProxy for AT mode
        // return new DataSourceProxy(druidDataSource);

        // DataSourceProxyXA for XA mode
        return new DataSourceProxyXA(druidDataSource);
    }
Copy the code

conclusion

At the current stage of technological development, there is no single distributed transaction processing mechanism that can perfectly meet the needs of all scenarios.

Consistency, reliability, ease of use, performance and many other aspects of the system design constraints, need to use different transaction processing mechanisms to meet.

The core value of the Seata project is to build a standardized platform that comprehensively addresses distributed transaction issues.

Based on Seata, the upper application architecture can flexibly choose appropriate distributed transaction solutions according to the requirements of actual scenarios

The addition of XA mode fills the gap of Seata in the global consistency scenario, forming the territory of four transaction modes: AT, TCC, Saga and XA, which can basically meet the demands of distributed transaction processing in all scenarios.

Of course, both the XA model and the Seata project itself are far from perfect, leaving much to be desired. We welcome everyone to participate in the construction of the project, and jointly create a standardized distributed transaction platform.

Your “like” is the best support and motivation for me. Pay attention to Solomon_ Xiao Ge shell structure, follow-up efforts to launch high-quality content.

Chat 🏆 technology project stage v | distributed those things…