问题出现:
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
属性来防止某些特定的运行时异常导致事务回滚,但通常建议仔细考虑是否真的需要这样做,并确保你的业务逻辑和数据完整性不会因此受到损害。
最终解决方案
上面的方法尝试都是不可以的,最后 NOT_SUPPORTED 完成
@Transactional(propagation = Propagation.NOT_SUPPORTED)
欢迎大家交流,如果有更多更好的结局方案
--end--