当捕获 UniqueConstraintViolationException 并重试保存操作时，若仍使用声明式 @Transactional，Spring 会因异常发生而标记事务为“rollback-only”，即使后续重试成功，整个事务仍会回滚，导致 500 错误。需改用编程式事务或调整传播行为来隔离重试逻辑。
当捕获 `uniqueconstraintviolationexception` 并重试保存操作时，若仍使用声明式 `@transactional`，spring 会因异常发生而标记事务为“rollback-only”，即使后续重试成功，整个事务仍会回滚，导致 500 错误。需改用编程式事务或调整传播行为来隔离重试逻辑。
在 Spring 的声明式事务管理中，@Transactional 方法一旦抛出未被捕获的运行时异常（如 RuntimeException 及其子类），Spring 默认将当前事务标记为 rollbackOnly。关键点在于：该标记不可撤销——即使你在 catch 块中成功处理了异常并完成了后续逻辑，只要事务上下文内曾发生过符合条件的异常，最终提交时就会触发 Transaction rolled back because it has been marked as rollback-only，从而返回 500 错误。
你提供的代码中，m2() 方法虽用 try-catch 捕获了 UniqueConstraintViolationException，但该异常本质是 DataIntegrityViolationException 的子类，属于 RuntimeException，且 m2() 自身也标注了 @Transactional。这意味着：
- 第一次
save()失败 → 抛出异常 → 当前事务（由m2()启动）被标记为 rollback-only； - 尽管
catch中修改版本并重试成功，事务状态已不可逆； -
m2()返回后，m1()继续执行m3()，但整个外层事务（由m1()启动）同样因内层事务污染而无法提交。
✅ 正确解决方案：隔离重试逻辑的事务边界
最推荐的方式是将唯一性冲突的重试逻辑封装在独立的、新启动的事务中，使其失败不影响外层业务流程。有两种主流实现：
方案一：编程式事务（推荐，显式可控）
@Service
public class EventService {
@Autowired
private PlatformTransactionManager transactionManager;
@Autowired
private EventRepository eventRepo;
@Transactional
public void m1(Event event) {
// ✅ 外层事务：负责整体业务一致性（如 m2 + m3）
m2(event); // 内部事务已隔离，不会污染 m1
m3();
// 成功则自动提交
}
// ❌ 移除 @Transactional：不再参与外层事务
public void m2(Event event) {
boolean success = false;
while (!success) {
try {
// ⚠️ 在新事务中执行保存，失败仅回滚该次尝试
saveWithNewTransaction(event);
success = true;
} catch (DataIntegrityViolationException e) {
if (e.getCause() instanceof SQLException sqlEx &&
sqlEx.getSQLState().equals("23505")) { // PostgreSQL 唯一约束码
event.setVersion(event.getVersion() + 1);
} else {
throw e; // 其他异常不重试，向上抛出
}
}
}
}
// ✅ 独立事务方法：每次重试都开启全新事务
private void saveWithNewTransaction(Event event) {
DefaultTransactionDefinition def = new DefaultTransactionDefinition();
def.setPropagationBehavior(TransactionDefinition.PROPAGATION_REQUIRES_NEW);
TransactionStatus status = transactionManager.getTransaction(def);
try {
eventRepo.save(event);
transactionManager.commit(status);
} catch (Exception e) {
transactionManager.rollback(status);
throw e;
}
}
@Transactional
public void m3() {
// 其他数据库操作...
}
}方案二：声明式事务 + REQUIRES_NEW（更简洁）
// 直接在重试方法上指定独立事务
@Transactional(propagation = Propagation.REQUIRES_NEW)
public void saveEventWithRetry(Event event) {
boolean success = false;
while (!success) {
try {
eventRepo.save(event);
success = true;
} catch (DataIntegrityViolationException e) {
if (isUniqueConstraintViolation(e)) {
event.setVersion(event.getVersion() + 1);
} else {
throw e;
}
}
}
}
// m2 调用它即可，无需手动管理事务
public void m2(Event event) {
saveEventWithRetry(event);
}? 提示：
isUniqueConstraintViolation()可根据数据库类型判断（如 H2 用"23000"，MySQL 用SQLState: 23000或ErrorCode: 1062），确保只对唯一冲突重试。
⚠️ 注意事项与最佳实践
-
不要在
@Transactional方法内吞掉所有RuntimeException：Spring 不关心你是否catch，只看是否抛出到事务代理边界。若异常被完全捕获且未重新抛出，事务可正常提交；但若方法本身有@Transactional，而内部调用又触发了异常（即使被捕获），需确保该异常不来自同一事务上下文。 - 避免无限重试：实际场景中应添加最大重试次数和指数退避，防止死循环或雪崩。
-
版本号并发安全：若多线程同时操作同一事件，建议结合
@Version乐观锁或数据库SELECT FOR UPDATE，否则可能覆盖彼此的版本更新。 -
日志追踪：在重试前后记录
event.getId()和event.getVersion()，便于问题排查。
通过将冲突处理逻辑下沉至独立事务边界，你既能优雅应对数据竞争，又能保障主业务流程的事务完整性——这才是 Spring 事务管理的正确打开方式。
