ShardingSphere 4.x Distributed Transaction-Supported function

Navigation

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

• Local transaction
• 2PC transaction-XA
• Seata BASE transaction

Local Transaction

Function

• Fully support none-cross-database transactions, for example, sharding table or sharding database with its route result in one database.
• Fully support cross-database transactions caused by logic exceptions, for example, the update of two databases in one transaction, after which, databases will throw null cursor and the content in both databases can be rolled back.
• Do not support the cross-database transactions caused by network or hardware exceptions. For example, after the update of two databases in one transaction, if one database is down before submitted, then only the data of the other database can be submitted.

Support

• Sharding-JDBC and Sharding-Proxy can innately support local transaction.

2PC Transaction — XA

Function

• Support cross-database XA transactions after sharding.
• Operation atomicity and high data consistency in 2PC transactions.
• When service is down and restarted, commit and rollback transactions can be recovered automatically.
• An SPI mechanism that integrates mainstream XA managers: Atomikos default and Narayana and Bitronix optional.
• Support XA and non-XA connection pool in the same time.
• Provide spring-boot and namespace access.

Not Support

• Recover committing and rolling back in other machines after the service is down.

BASE Transaction Saga

Function

• Fully support cross-database transactions.
• Re-try failed SQL and try to deliver it.
• Support reverted SQL, update snapshot auto-generation and auto-compensation.
• Use relational databases to take snapshot and persist transaction log; support SPI to load other persistent data.

Unsupported

• Not support resource isolation for now.
• Not support automatic recovery of commit and rollback after the service is down for now.

Support

Our BASE transaction has implemented Saga transaction through third party SPI and uses Servicecomb-Saga as Saga engine.

Notice

• Reverted SQL requires a primary key, please make sure it is defined in table structure.
• For INSERT statements, primary key value needs to be shown in SQL, such as INSERT INTO ${table_name} (id, value, ...) VALUES (11111, '', ....) (id means table primary key).
• ShardingSphere distributed primary key can be used to automatically generate the primary key.

Saga BASE Transaction

Function

• Fully support cross-database transactions.
• Support RC isolation.
• Rollback transaction according to undo snapshot.
• Support recovery committing/rolling back transaction automatically after the service is down.

Prerequisite

• Need to deploy seata-server process to do transaction coordination.

Need to Optimize

• SQL will be parsed twice by ShardingSphere and Seata.