To let users better understand the design of BASE transactions, we need to explain some concepts first:
When ShardingSphere parses SQL, transaction engine will shift current transactions to a new branch transaction group. Before executing the routed physical SQL, the transaction engine will take snapshot of these SQL and register corresponding branch transactions to the current branch transaction group. After all the SQL are parsed and executed in the transaction, it may contain multiple branch transaction groups and each group may contain multiple branch transactions, as the following picture:
At last, when users commit transactions, the Saga engine, according to the order of branch transaction groups, will use route SQL to retry or reverted SQL to rollback.