Spring Boot中@Transactional事务异常回滚问题咨询

核心差异：JPA延迟执行 vs JdbcTemplate立即执行 #

1. JPA场景触发回滚的真实原因 #

你用EntityManager.merge()时，这个操作不会立刻执行SQL，只是把实体标记为待更新状态，实际SQL会延迟到事务提交前的flush阶段才执行。也就是说：

• 调用errorB()的时候，超长字段的插入逻辑根本没真正执行；
• 当B()方法的try-catch块走完、Spring准备提交事务时，JPA才会触发flush执行SQL，这时候抛出的字段超长异常不在你的try-catch范围内；
• Spring事务拦截器会捕获到这个未被处理的RuntimeException（JPA会把数据库约束异常包装成PersistenceException，属于RuntimeException子类），按照默认规则触发全事务回滚，包括trueA()的插入操作。

2. JdbcTemplate不回滚的逻辑 #

JdbcTemplate.execute()是立即执行SQL，字段超长的异常在调用errorInsert()时就直接抛出，刚好被B()方法的try-catch块捕获处理。Spring事务拦截器看到B()方法没有抛出未处理的异常，就不会触发回滚，所以trueInsert()的插入操作会保留。

验证与解决方案 #

验证延迟执行问题 #

你可以在errorB()里手动调用em.flush()，强制立即执行SQL，此时异常会在try块内抛出，被catch处理，事务就不会回滚：

public void errorB(){
    UserEntity userEntity1 = new UserEntity();
    userEntity1.setName("ceshi111111111111111111111111111111111111111111111111111111");
    em.merge(userEntity1);
    em.flush(); // 强制立即执行SQL，异常会在这里抛出
}

其他注意事项 #

• Spring声明式事务默认只对未捕获的RuntimeException/Error触发回滚，检查型异常不会。但JPA会把绝大多数数据库异常包装成RuntimeException，这点要格外留意；
• 如果需要更精细的事务控制，可以用TransactionStatus.setRollbackOnly()手动标记回滚，或者在@Transactional注解中配置rollbackFor/noRollbackFor参数自定义回滚规则。

内容的提问来源于stack exchange，提问作者mgcc