本文将介绍PolarDB-X 事务常见问题。
分布式事务二阶段提交断网如何保证事务的一致性，当节点事务执行失败，事务整体是否会回滚？
Commit前，会对发生写入的不同分库进行两阶段的Prepare Phase操作：
如果Prepare Phase成功了，即使因为断网在Commit阶段失败了，后续实例恢复后，也会根据已写入的事务日志保证这个事务继续提交下去。
如果Prepare Phase不成功，那这个分布式事务就会返回失败。
用户业务侧调用SDK操作分布式事务如事务回滚了，客户端如何感知数据已经不一致？
事务执行结果反馈机制：若数据库处理过程中发生任何错误，系统会明确返回失败状态给应用侧，仅在数据库所有操作成功完成时，才会返回成功响应。
数据一致性保障：当分布式事务返回失败时，意味着所有参与分库的事务均未提交（或已全部回滚）。这种状态下，其他应用程序读取数据时绝对不会观察到不一致的中间状态。
部分提交场景处理：在分布式事务处理过程中，可能出现部分分库事务已提交而其他分库未提交的中间状态，PolarDB-X 2.0通过TSO（Timestamp Oracle）机制确保：其他应用程序读取时只能看到完整提交的事务数据，严格维护事务的ACID特性，实现强一致分布式事务。
当分布式事务中存在两个SQL，如果在Commit阶段SQL1成功，SQL2失败。此时如果回滚的话SQL1会回滚，SQL2是否也会回滚？
BEGIN;
UPDATE account SET balance = balance - 20 WHERE name = 'Alice'; //sql 1
UPDATE account SET balance = balance + 20 WHERE name = 'Bob'; //sql 2
COMMIT;PolarDB-X的分布式事务提交分为Prepare和Commit两个阶段：
Prepare阶段：各分片（DN）执行事务预提交，锁定资源并确保事务可执行。
Commit阶段：事务协调节点（CN）向所有参与节点发送最终提交指令。
不同阶段的失败处理机制
在Commit阶段失败（SQL1语句成功，SQL2语句失败）
由于事务已进入Commit阶段，说明Prepare阶段已全部成功，因此该事务最终必定会成功提交。
CN 会持续后台重试Commit SQL2语句，直至成功。
数据一致性保障：
即使SQL2语句暂时未提交，TSO（Timestamp Oracle）机制 会确保其他事务读取的数据仍然保持一致（仅能看到完整提交的事务）。
不会出现部分可见（partial visibility）的情况。
在Prepare阶段失败（SQL2语句失败，SQL1语句成功）
整个事务会被判定为失败，并自动回滚。
SQL1语句的修改会被撤销（由于仅处于Prepare阶段，数据未实际提交）。
数据一致性保障：其他事务不会看到Prepare阶段的中间状态，因此不会出现不一致现象。