当使用 @Transactional 注解时，Spring 默认对未检查异常（如 RuntimeException 及其子类）执行强制回滚；即使你在方法内捕获并处理了该异常，外层事务仍会被标记为“rollback-only”，导致最终提交失败并返回 500 错误。
当使用 `@transactional` 注解时，spring 默认对未检查异常（如 `runtimeexception` 及其子类）执行强制回滚；即使你在方法内捕获并处理了该异常，外层事务仍会被标记为“rollback-only”，导致最终提交失败并返回 500 错误。
在 Spring 的声明式事务管理中，@Transactional 的行为遵循一个关键原则：一旦事务上下文中抛出了符合条件的异常（默认是 RuntimeException 和 Error），Spring 就会将当前事务标记为 rollbackOnly。此后，无论你是否在 catch 块中优雅地处理了该异常、重试了操作，甚至后续所有数据库写入都成功，只要事务状态已被标记为回滚，最终 commit() 就会失败，并抛出类似 Transaction rolled back because it has been marked as rollback-only 的错误——这正是你收到 500 响应的根本原因。
你的代码中，m2() 内部虽然捕获了 UniqueConstraintViolationException 并通过自增版本重试，但该异常最初是由 JPA/Hibernate 在 eventRepo.save(event) 执行过程中抛出的，而此时它已处于 m1() 的事务作用域内。Spring 在异常穿透出 m2() 时（哪怕被 m2() 捕获），并不会重置事务状态；更准确地说，异常虽被局部捕获，但事务同步器（TransactionSynchronizationManager）中的 rollbackOnly 标志一旦设置，就不可逆。因此，当控制流回到 m1() 并试图完成事务时，Spring 拒绝提交，触发 HTTP 500。
✅ 正确解法：使用编程式事务隔离重试逻辑
为避免污染外层事务，需将“带重试的唯一键冲突处理”封装在一个独立、可自主控制生命周期的新事务中。推荐采用 PlatformTransactionManager + TransactionTemplate（更简洁）或手动 TransactionStatus 管理：
@Autowired
private PlatformTransactionManager transactionManager;
@Transactional // 外层事务：负责 m1 本身的业务一致性（如 m3 调用）
public void m1(Event event) {
// 使用 REQUIRES_NEW 启动独立子事务，失败不影响外层
TransactionTemplate txTemplate = new TransactionTemplate(transactionManager);
txTemplate.setPropagationBehavior(TransactionDefinition.PROPAGATION_REQUIRES_NEW);
// 在新事务中执行带重试的保存逻辑
txTemplate.execute(status -> {
m2(event); // 此处的异常仅影响当前子事务
return null;
});
// 子事务成功提交后，继续执行其他操作
m3(); // 此调用仍在 m1 的原始事务中
}
同时精简 m2()，移除事务注解与冗余循环结构（保持专注单一职责）：
public void m2(Event event) {
while (true) {
try {
eventRepo.save(event);
return; // 成功则退出
} catch (DataIntegrityViolationException e) {
if (e.getCause() instanceof SQLException sqlEx
&& sqlEx.getSQLState().equals("23505")) { // PostgreSQL 唯一键
event.setVersion(event.getVersion() + 1);
} else {
throw e; // 非预期异常，向上抛出
}
}
}
}
⚠️ 注意事项与最佳实践
-
不要滥用
@Transactional嵌套：m2()上的@Transactional不会创建新事务（默认REQUIRED），反而可能因代理机制失效或传播行为混淆加剧问题。 -
精准匹配异常类型：
UniqueConstraintViolationException是 Hibernate 特有异常，不同方言（如 H2、MySQL、PostgreSQL）底层 SQL 异常不同，建议捕获更通用的DataIntegrityViolationException并根据SQLException.getSQLState()或消息做细粒度判断。 -
防止无限重试：生产环境务必添加最大重试次数和退避策略（如
Thread.sleep(10)），避免 CPU 打满或死循环：int maxRetries = 5; for (int i = 0; i
-
替代方案考虑：若版本号生成具备确定性（如时间戳+序列），可改用
INSERT ... ON CONFLICT DO UPDATE（PostgreSQL）或INSERT IGNORE（MySQL）等数据库原生 UPSERT 语义，彻底规避应用层重试。
通过将冲突处理逻辑下沉至独立事务边界内，你既能保证业务最终一致性，又能确保外层事务健康提交，最终稳定返回 HTTP 201 Created。
