Java 1.6 + iBatis 多表插入时 @Transactional 无法回滚的常见原因？

Question

在 Java 1.6 + iBatis（即 MyBatis 前身）环境下，使用 `@Transactional` 注解进行多表插入时事务无法回滚的**最常见原因**是：**未正确配置事务管理器或事务代理失效**。具体表现为：① Spring 配置中遗漏 `` 或未声明 `TransactionManager` Bean；② Service 方法被本类内其他非事务方法直接调用（即“self-invocation”），导致 AOP 代理失效，`@Transactional` 不生效；③ iBatis 使用了 `SqlMapClientTemplate` 等过时模板类，而未交由 Spring 管理 SqlMapClient，导致事务上下文未绑定；④ 数据库引擎不支持事务（如 MySQL 的 MyISAM 表）；⑤ 异常被捕获未抛出（如 try-catch 吞掉 RuntimeException）。注意：Java 1.6 与 iBatis 2.x 组合下，Spring 2.5+ 是主流适配版本，需确保事务传播行为、异常类型（默认仅对 `RuntimeException` 回滚）及数据源配置均一致有效。

Answer 1

```html

一、现象层：事务“静默失败”——看似执行成功，实则未回滚

在 Java 1.6 + iBatis 2.3.x + Spring 2.5.6 组合下，开发者常观察到：多表插入中某条 SQL 报错（如主键冲突、外键约束失败），但前序已执行的 INSERT 语句未被撤销，数据库残留脏数据。日志中无 Transaction rolled back 提示，@Transactional 像“失效”一样静默——这并非注解本身 bug，而是事务上下文根本未建立或未激活。

二、配置层：事务管理器缺失或错配——地基不牢，大厦将倾

• Spring 配置中遗漏 <tx:annotation-driven/>，导致 @Transactional 元素完全被忽略（AOP 切面未注册）；
• 未声明 TransactionManager Bean，或声明为 DataSourceTransactionManager 但实际使用了 JTA 数据源（如 WebLogic JNDI）；
• iBatis SqlMapClient 未通过 SqlMapClientFactoryBean 交由 Spring 管理，而是手工 new 实例，导致无法绑定 Spring 事务同步器（TransactionSynchronizationManager）。

三、代理层：“self-invocation”陷阱——本类调用绕过 AOP 代理

典型反模式代码：

public class OrderService {
  public void createOrder(Order order) {
    insertOrder(order);          // ❌ 直接调用本类方法 → 无代理拦截
    insertOrderItems(order.getItems()); 
  }
  @Transactional
  public void insertOrder(Order o) { ... } // 注解失效！
}

原因：Spring 默认使用 JDK 动态代理（接口代理），若目标类无接口，则 fallback 为 CGLIB 代理——但无论哪种，本类内方法调用均不经过代理对象，事务切面彻底丢失。

四、数据层：存储引擎与异常类型双重失守

问题维度	具体表现	验证方式
MySQL 引擎	表使用 MyISAM（非事务型），INSERT 永不回滚	SHOW CREATE TABLE t_order; 查看 ENGINE=InnoDB
异常类型	捕获 SQLException 后仅 log，未 re-throw；或抛出 CheckedException（如 IOException）	默认 @Transactional 仅对 RuntimeException 及其子类回滚

五、治理层：五步诊断法与加固方案

1. 检查代理生效性：在事务方法入口加 log.info("Proxy: {}", AopContext.currentProxy())（需启用 expose-proxy="true"）；
2. 验证事务传播：显式指定 @Transactional(propagation = Propagation.REQUIRED, rollbackFor = Exception.class)；
3. 替换模板类：弃用 SqlMapClientTemplate，改用 Spring 管理的 SqlMapClient + SqlMapClientDaoSupport；
4. 统一数据源：确保 DataSourceTransactionManager 与 iBatis 的 dataSource 指向同一物理连接池实例；
5. 启用事务日志：设置 log4j.logger.org.springframework.transaction=DEBUG，观察 Creating new transaction / Initiating transaction rollback。

六、架构演进视角：从 iBatis 到 MyBatis 的事务一致性启示

graph TD A[Java 1.6 + iBatis 2.x] -->|依赖 Spring 2.5+| B[DataSourceTransactionManager] B --> C{SqlMapClient 是否由
SqlMapClientFactoryBean 创建？} C -->|否| D[事务上下文未绑定
→ 回滚失效] C -->|是| E[检查代理链是否完整] E --> F[是否存在 self-invocation？] F -->|是| G[重构为 Service 接口调用
或注入自身代理] F -->|否| H[验证数据库引擎与异常策略]

该流程图揭示：事务失效本质是“上下文断链”——从 Spring 容器到 iBatis 执行器，任一环节脱离事务管理器管控，即导致 ACID 保障瓦解。在遗留系统维护中，此链路比代码逻辑更需敬畏。

```