java业务层统一管理数据库事务的核心是确保多dao操作共享同一事务上下文，实现“全成功或全失败”；常用@transactional声明式管理，需spring bean且走代理调用；复杂场景可用transactiontemplate编程式控制；跨数据源或外部调用需分布式事务或补偿机制。
Java 业务层统一管理数据库事务，核心目标是让多个 DAO 或 Mapper 的操作共享同一个事务上下文，确保“全成功或全失败”。不靠手动传 Connection，而是通过框架能力或轻量设计实现事务边界清晰、复用性强、不易出错。
用 @Transactional 声明式管理（最常用）
Spring 环境下，这是首选方式。只需在 Service 方法上加注解，Spring 自动完成事务开启、提交或回滚：
- 方法执行前，Spring 通过 AOP 拦截，由 PlatformTransactionManager 获取连接、设置
setAutoCommit(false) - 方法内所有 DAO 操作（JdbcTemplate、MyBatis Mapper、JPA Repository）都复用该连接
- 方法正常结束 → 自动
commit；抛出未捕获的 RuntimeException（或按rollbackFor指定的异常）→ 自动rollback - 注意：必须是 Spring 管理的 Bean，且调用需走代理（避免本类 self-invocation 导致事务失效）
用 TransactionTemplate 编程式控制（需灵活干预时）
当事务逻辑不能完全由方法边界定义（比如部分操作要事务、部分不要，或运行时决定隔离级别），可用 TransactionTemplate：
- 注入
TransactionTemplate，调用execute()并传入TransactionCallback - 在回调中写业务代码，可手动调用
TransactionStatus.setRollbackOnly()触发回滚 - 适合日志记录+主流程分离、条件性事务、嵌套子事务等场景
跨多数据源或分布式场景的处理
单机多表事务天然支持，但以下情况无法靠本地事务保证一致性：
- 多个 MySQL 实例 / 不同数据库：本地事务无效，需用 Seata（AT/TCC 模式）、RocketMQ 半消息等分布式事务方案
- 调外部 HTTP 接口 / 发 MQ 消息：这些操作不在事务范围内，需配合补偿机制或最终一致性设计（如事务消息 + 本地事务表）
- 新线程内操作 DB：ThreadLocal 中的事务上下文不会自动传递，会导致无事务，应避免或显式传播
关键细节与避坑点
统一管理不是加个注解就万事大吉，还要注意这些实际约束：
- 所有 DAO 必须使用同一个数据源（同一
DataSource配置），否则事务不生效 - @Transactional 默认只对 RuntimeException 回滚；若业务异常是 checked exception，需显式写
rollbackFor = Exception.class - 事务方法内调用另一个 service 的非事务方法，若传播行为是 REQUIRED（默认），仍属同一事务；但若对方用了 REQUIRES_NEW，则会另起事务，原事务不受其回滚影响
- 连接池环境下，事务结束后务必恢复
autoCommit=true（Spring 会自动处理，但手写 JDBC 时需注意）
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
