Spring: try-catch 是否还会回滚

问题出现：

try-catch 语句依旧会抛出如下错误

org.springframework.transaction.TransactionSystemException: Could not commit JPA transaction; nested exception is javax.persistence.RollbackException: Transaction marked as rollbackOnly
	at org.springframework.orm.jpa.JpaTransactionManager.doCommit(JpaTransactionManager.java:526)
	at org.springframework.transaction.support.AbstractPlatformTransactionManager.processCommit(AbstractPlatformTransactionManager.java:761)
	at org.springframework.transaction.support.AbstractPlatformTransactionManager.commit(AbstractPlatformTransactionManager.java:730)
	at org.springframework.transaction.interceptor.TransactionAspectSupport.commitTransactionAfterReturning(TransactionAspectSupport.java:518)
	at org.springframework.transaction.interceptor.TransactionAspectSupport.invokeWithinTransaction(TransactionAspectSupport.java:292)
	at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:96)

问题解决：

`try-catch` 为什么还会事务回滚

在编程中，使用 try-catch 语句块确实可以帮助你捕获和处理异常，但这并不直接影响数据库事务的提交或回滚。事务的提交或回滚通常是由事务管理器根据事务的边界和事务属性（如隔离级别、传播行为等）来控制的，而不是直接由 try-catch 语句块控制的。

然而，有几个原因可能导致在使用 try-catch 时事务仍然回滚：

未捕获的异常 ：如果事务中的代码抛出了未被 try-catch 捕获的异常，那么这个异常将传播到事务的边界，导致事务管理器触发回滚操作。
运行时异常 ：在 Spring 等框架中，默认情况下，运行时异常（RuntimeException 及其子类）会导致事务回滚。即使你在 try-catch 中捕获了这些异常，如果没有显式地调用事务的提交方法（在大多数场景下，这是不必要的，因为框架会为你管理事务），事务管理器仍然会根据异常的类型和配置来决定是否回滚事务。
事务传播行为 ：如果你在一个已经存在的事务中开始了一个新的事务（例如，使用了 Spring 的 @Transactional 注解，并且事务的传播行为是 REQUIRED 或其他允许嵌套事务的行为），那么内部事务的异常可能会影响到外部事务的状态，导致外部事务也回滚。这取决于具体的事务管理器和配置。
事务回滚的显式请求 ：在某些情况下，你的代码可能显式地请求了事务回滚，即使异常被捕获了。例如，在 Spring 中，你可以通过编程方式调用 TransactionStatus.setRollbackOnly() 来标记事务需要回滚。
框架或容器的行为：使用的框架或容器（如 Spring、EJB 等）可能有自己的事务管理策略，这些策略可能会根据捕获的异常类型、事务的属性或其他因素来决定是否回滚事务。
数据库约束：即使你的代码中没有异常，数据库级别的约束（如主键冲突、外键约束等）也可能导致 SQL 语句执行失败，从而触发事务回滚。

因此，当你看到即使使用了 try-catch 事务仍然回滚时，你应该检查以下几点：

是否有未捕获的异常。
是否捕获了运行时异常但期望事务继续。
事务的传播行为和嵌套事务的处理方式。
是否有显式地请求事务回滚的代码。
数据库约束是否可能导致事务失败。

此外，了解你使用的框架或容器的事务管理策略和配置也是非常重要的。

捕获了运行时异常但期望事务继续

在大多数现代Java框架（如Spring）中，运行时异常（RuntimeException 及其子类）默认会导致事务回滚。这是因为运行时异常通常表示程序中的错误，这些错误可能破坏了数据的完整性或一致性，因此框架选择自动回滚事务以避免潜在的问题。

然而，如果你捕获了运行时异常但仍然希望事务继续（即不触发回滚），你需要采取一些额外的步骤来确保这一点。但是，请注意，这种做法通常是不推荐的，因为它可能隐藏了潜在的问题并导致数据不一致。

在Spring框架中，你可以通过以下几种方式来处理这个问题：

使用@Transactional(noRollbackFor = ...)或@Transactional(noRollbackForClassName = ...)

你可以在服务层的方法上使用@Transactional注解，并通过noRollbackFor或noRollbackForClassName属性来指定哪些异常不应该导致事务回滚。但是，请注意这些属性只接受编译时异常（即那些继承自Exception但不继承自RuntimeException的异常）。对于运行时异常，你需要使用@Transactional(rollbackFor = Exception.class, noRollbackFor = YourSpecificRuntimeException.class)这样的组合，但实际上由于Exception.class已经包括了所有的异常，所以只需要noRollbackFor就足够了。但更常见的做法是将rollbackFor留空，仅使用noRollbackFor。

然而，由于noRollbackFor不直接支持运行时异常，你需要显式地列出不希望回滚的运行时异常类型。

@Transactional(noRollbackFor = YourSpecificRuntimeException.class)
public void yourServiceMethod() {
try {
// 可能会抛出 YourSpecificRuntimeException 的代码
} catch (YourSpecificRuntimeException e) {
// 处理异常，但希望事务继续
// 注意：这里不会阻止事务回滚，因为@Transactional的noRollbackFor属性需要精确匹配
}
}

但是，由于Spring的@Transactional注解在方法边界上处理事务，并且不直接检查方法体内部的异常处理逻辑，因此上述noRollbackFor的使用实际上是在说："如果这个方法抛出了YourSpecificRuntimeException，请不要回滚事务。" 它并不依赖于你是否在方法内部捕获了这个异常。

编程式事务管理

如果你需要更细粒度的控制，可以考虑使用编程式事务管理。这允许你在代码中显式地开始、提交或回滚事务。但是，这种方法更加复杂，并且通常不推荐用于服务层方法，因为它与声明式事务管理相比更加繁琐且容易出错。
重新考虑异常处理策略

最后，你可能需要重新考虑你的异常处理策略。通常，如果一个运行时异常表明数据可能已经处于不一致的状态，那么回滚事务是保护数据完整性的正确做法。如果你的业务逻辑允许在发生特定运行时异常时继续执行（尽管这很少见），你可能需要重新设计你的业务逻辑或异常处理逻辑，以确保数据的一致性和完整性不会受到影响。

总的来说，虽然你可以通过@Transactional注解的noRollbackFor属性来防止某些特定的运行时异常导致事务回滚，但通常建议仔细考虑是否真的需要这样做，并确保你的业务逻辑和数据完整性不会因此受到损害。

--end--

Spring: try-catch 是否还会回滚

问题出现：

问题解决：

try-catch 为什么还会事务回滚

捕获了运行时异常但期望事务继续

`try-catch` 为什么还会事务回滚