JDBC无法直接处理分布式事务，因其仅绑定单个Connection；需通过JTA+XA、补偿型模式（TCC/Saga）或Seata等框架实现跨库事务协调。
Java 中 JDBC 层面无法直接处理分布式事务，因为它天然只绑定单个 Connection，而分布式事务必须跨越多个数据库连接、服务或资源。要突破这个局限，核心思路不是“在 JDBC 内部扩展它”，而是绕过它的边界，用更高层的协调机制来统管多个 JDBC 事务。
明确 JDBC 的硬性限制
JDBC 事务本质是本地事务，依赖单一数据库连接（Connection）的 commit() 和 rollback() 方法。它的局限性非常明确：
- 一个
Connection只能连一个数据库实例，不能跨库、跨服务、跨数据源； - 没有内置的事务传播能力，无法将事务上下文传递给远程调用；
- 不感知其他资源（如消息队列、缓存）的状态，无法参与多资源协同；
- 没有全局事务 ID、分支注册、回滚日志等分布式事务必需元数据支持。
用 JTA + XA 驱动桥接 JDBC 到分布式事务
这是最贴近 JDBC 层但仍可实现分布式事务的标准路径：把 JDBC 资源包装成 XA 兼容的参与者，交由 JTA 事务管理器统一调度。
- 底层仍用 JDBC 驱动，但必须选用支持
XADataSource的版本（如 MySQL Connector/J 8.0+ 的MysqlXADataSource）； - 应用通过 JNDI 或 Spring 的
JtaTransactionManager获取全局事务上下文； - 每个数据库连接由
XAConnection创建，并注册为事务分支（Branch），由 TM 控制其 prepare/commit/rollback； - 代码里不再手动调用
conn.commit()，所有提交行为由 JTA 协调器在第二阶段统一触发。
用补偿型模式替代强一致性 JDBC 事务
当 XA 成本过高或数据库不支持 XA 时，放弃“JDBC 事务升级”，转而设计可被 JDBC 执行的补偿逻辑：
立即学习“Java免费学习笔记（深入）”；
- TCC 模式：每个服务提供
try（预留资源，用普通 JDBC 插入冻结记录）、confirm（正式扣减，JDBC 更新）、cancel（释放冻结，JDBC 回滚状态）三阶段操作； - Saga 模式：把长事务拆成一系列本地 JDBC 事务，每步成功后发消息触发下一步，失败则按反向顺序执行补偿 SQL；
- 关键点：所有 SQL 操作仍是标准 JDBC，但业务逻辑主动承担了事务协调职责，不再依赖底层连接的原子性保证。
引入 Seata 等框架封装 JDBC 调用细节
Seata 的 AT（Auto Transaction）模式对开发者最友好：它在不改 JDBC 用法的前提下，自动增强事务能力。
- 你仍写
update、insert等原生 JDBC 或 MyBatis 语句； - Seata 在数据源代理层拦截 SQL，自动生成
UNDO_LOG表记录前镜像，并在回滚时执行反向 SQL； - 全局事务由
@GlobalTransactional注解开启，底层通过 TC（Transaction Coordinator）协调各分支的提交或回滚； - 本质上，它把分布式事务的复杂性下沉到框架层，JDBC 层保持干净、简单、可控。
