当使用 @Transactional 注解时，即使捕获了 UniqueConstraintViolationException 并重试保存操作，Spring 仍会因事务上下文中已发生异常而强制回滚——这是默认的“只读异常传播”机制所致。本文详解原因并提供可落地的编程式事务与声明式事务两种解决方案。
当使用 `@transactional` 注解时，即使捕获了 `uniqueconstraintviolationexception` 并重试保存操作，spring 仍会因事务上下文中已发生异常而强制回滚——这是默认的“只读异常传播”机制所致。本文详解原因并提供可落地的编程式事务与声明式事务两种解决方案。
在 Spring 的声明式事务管理中，@Transactional 方法一旦抛出 未被捕获的运行时异常（如 RuntimeException 及其子类），Spring 会自动标记当前事务为 rollbackOnly。关键点在于：即使该异常在方法内部被 catch 住、未向上抛出，只要它曾发生在当前事务上下文中，Spring 就已记录该事务“不安全”，后续无论是否重试成功，最终提交时都会触发回滚并抛出 TransactionSystemException（表现为 500 错误）。
你提供的代码中，m2() 虽在 while 循环内捕获了 UniqueConstraintViolationException 并自增版本重试，但该异常实际已由 JPA/Hibernate 在底层事务中触发，Spring 的事务拦截器早已感知并标记事务为回滚状态。因此，尽管 m2() 最终成功、m3() 也执行完毕，整个 m1() 方法结束时事务仍无法提交，最终返回 HTTP 500。
✅ 正确解决方案一：编程式事务（推荐用于重试逻辑）
通过 PlatformTransactionManager 手动控制事务边界，将重试逻辑完全隔离在独立事务中，避免污染外层事务：
@Autowired
private PlatformTransactionManager transactionManager;
void m1(Event event) {
// 启动一个全新的、独立的事务（PROPAGATION_REQUIRES_NEW）
DefaultTransactionDefinition def = new DefaultTransactionDefinition();
def.setPropagationBehavior(TransactionDefinition.PROPAGATION_REQUIRES_NEW);
TransactionStatus status = transactionManager.getTransaction(def);
try {
m2(event); // 此处的重试完全在新事务内完成
m3(); // 外层业务逻辑（如日志、通知等）
transactionManager.commit(status); // 显式提交
} catch (Exception e) {
transactionManager.rollback(status); // 显式回滚
throw new RuntimeException("Failed to persist event after retries", e);
}
}
// 注意：移除 @Transactional，避免与编程式事务冲突
void m2(Event event) {
boolean success = false;
while (!success) {
try {
eventRepo.save(event);
success = true;
} catch (DataIntegrityViolationException e) { // 推荐捕获更通用的父类
if (e.getCause() instanceof SQLException sqlEx &&
sqlEx.getSQLState().startsWith("23")) { // SQL state 23xxx 表示完整性约束违规
event.setVersion(event.getVersion() + 1);
} else {
throw e; // 其他异常不重试，直接上抛
}
}
}
}
⚠️ 注意事项：
- 使用
PROPAGATION_REQUIRES_NEW确保m2()的重试在全新事务中执行，与m1()的事务完全解耦；- 捕获
DataIntegrityViolationException（Spring 抽象异常）比具体数据库异常更可移植；- 建议通过
SQLException.getSQLState()判断是否为唯一约束违规（如 PostgreSQL 为23505，MySQL 为23000），增强健壮性。
✅ 正确解决方案二：声明式事务 + 异常分类配置（简洁版）
若希望保留声明式事务风格，可通过 @Transactional(noRollbackFor = ...) 明确指定哪些异常不应触发回滚：
@Transactional(noRollbackFor = UniqueConstraintViolationException.class)
void m1(Event event) {
m2(event);
m3();
}
@Transactional(noRollbackFor = UniqueConstraintViolationException.class)
void m2(Event event) {
boolean success = false;
while (!success) {
try {
eventRepo.save(event);
success = true;
} catch (UniqueConstraintViolationException e) {
event.setVersion(event.getVersion() + 1);
}
}
}
✅ 优势：代码简洁，符合 Spring 编程习惯；
❗ 局限：要求UniqueConstraintViolationException精准匹配（注意包路径，如 Hibernate 的ConstraintViolationException或 Spring 的DataIntegrityViolationException），且所有重试必须在同一事务内完成——这意味着若m2()内重试多次，每次失败都会产生一次数据库 round-trip，可能影响性能。
? 总结建议
-
优先选用编程式事务方案：对重试逻辑有强控制需求（如指数退避、最大重试次数、跨服务补偿）时，
PlatformTransactionManager提供最高灵活性与清晰性； -
避免在
@Transactional方法中“静默吞掉”数据访问异常：Spring 的事务语义是“全有或全无”，异常即失败信号，掩盖它只会导致不可预测的回滚行为； -
补充防御性检查（可选）：在
save()前先eventRepo.existsByVersion(event.getVersion())，虽不能完全替代唯一约束（并发场景下仍有竞态），但可减少异常发生频率，提升平均性能。
通过以上任一方式，即可确保版本冲突时优雅重试、事务正常提交，并稳定返回 HTTP 201 成功响应。
