ShardingSphere 4.x Distributed Transaction-core concept

3 min readSep 1, 2020

Navigation

This chapter mainly introduces the core concepts of distributed transactions, including:

Local transaction
2PC transaction-XA
Seata BASE transaction

2PC TRANSACTION-XA

2PC transaction submit uses the DTP Model defined by X/OPEN, in which extracted AP, TM and RM can guarantee a high transaction consistency. TM and RM exchange transaction information according to XA. Compared with traditional local transactions, XA transactions have a prepare phase, where the database can not only passively receive commands, but also notify the submitter whether the transaction can be accepted. So TM can collect all the prepare results of transactions in branches before submitting all of them together, which has guaranteed the high consistency.

Java implements the XA model through defining a JTA interface, in which ResourceManager requires an XA driver provided by database manufacturers and TransactionManager is provided by transaction manager manufacturers. Traditional transaction managers need to be bound with application server, which poises a high use cost. But built-in transaction managers have already been able to provide services through jar packages. Integrated with ShardingSphere, it can guarantee the high consistency in cross-database transactions after sharding.

Usually, to use XA transaction, users must use its connection pool provided by transaction manager manufacturers. However, when ShardingSphere integrates XA transactions, it has separated the management of XA transaction and its connection pool, so XA will not invade the business.

Saga Transaction

The concept of Saga comes from a database paper Sagas more than 30 years ago. A Saga transaction is a long-term transaction consisting of several short-term transactions. In the distributed transaction scenario, we consider a saga distributed transaction as a transaction composed of multiple local transactions, each of which has a corresponding compensation transaction. During the execution of saga transaction, if an exception occurs in one step of execution, the saga transaction will be terminated, and the corresponding compensation transaction will be invoked to complete the relevant recovery operation, so as to ensure that the local transactions related to saga are either successfully executed or recovery to the state before the transaction is executed through compensation.

Compensation Automatically

Saga defines that each sub-transaction in a transaction has a corresponding reverse compensation operation. Saga transaction manager generates a directed acyclic graph based on the results of program execution, and invokes reverse compensation operations in reverse order according to the graph when a rollback operation is needed. Saga transaction manager is only used to control when to retry and compensate properly. It is not responsible for the content of compensation. The specific operation of compensation needs to be provided by developers themselves.

ShardingSphere uses reverse SQL technology to automatically generate reverse SQL for database updating operation, which is executed by saga-actuator. The use of ShardingSphere does not need to pay any more attention to how to implement compensation methods.

Seata BASE transaction

Seata is a distributed transaction framework developed by Alibaba Group and Ant Finance. As of 0.5.x, it includes AT and TCC transactions. The goal of AT transaction is to provide incremental transaction ACID semantics under the micro-service architecture, so that users can use distributed transactions as they use local transactions. The core idea of AT transaction is the same as ShardingSphere.

Seata AT transaction model

Seata AT transaction model includes TM (transaction manager), RM (resource manager), TC (transaction coordinator). TC is an independent service that needs to be deployed separately. TM and RM are deployed together with business applications in the form of jar packages. They establish long connections with TC and keep RPC communication throughout the transaction life cycle. The initiator of global transaction is TM, and the participant of global transaction is RM; TM is in charge of begin and commit/rollback of global transaction, RM is in charge of reporting the execution results of branch transaction, and commit/rollback is executed through TC coordination.