解决Could not commit JPA transaction RollbackException: Transaction marked as rollbackOnly

本文介绍了解决CouldnotcommitJPAtransactionRollbackException异常的方法。通过理解@Transactional注解的使用及其属性配置,提供了从EntityManager创建新事务的示例代码。

解决Could not commit JPA transaction RollbackException: Transaction marked as rollbackOnly

Could not commit JPA transaction RollbackException: Transaction marked as rollbackOnly:出现该错误的原因是使用@Transactional事务托管注解的方法或类事务已经被标记为值回滚,且不能再设置为不会滚。
首先了解下@Transactional注解:


@Transactional注解

@Transactional属性

属性类型描述
valueString可选的限定描述符,指定使用的事务管理器
propagationenum: Propagation可选的事务传播行为设置
isolationenum: Isolation可选的事务隔离级别设置
readOnlyboolean读写或只读事务,默认读写
timeoutint (in seconds granularity)事务超时时间设置
rollbackForClass对象数组,必须继承自Throwable导致事务回滚的异常类数组
rollbackForClassName 类名数组,必须继承自Throwable导致事务回滚的异常类名字数组
noRollbackForClass对象数组,必须继承自Throwable不会导致事务回滚的异常类数组
noRollbackForClassName 类名数组,必须继承自Throwable不会导致事务回滚的异常类名字数组

用法

@Transactional 可以作用于接口、接口方法、类以及类方法上。当作用于类上时,该类的所有 public 方法将都具有该类型的事务属性,同时,我们也可以在方法级别使用该标注来覆盖类级别的定义。

虽然 @Transactional 注解可以作用于接口、接口方法、类以及类方法上,但是 Spring 建议不要在接口或者接口方法上使用该注解,因为这只有在使用基于接口的代理时它才会生效。另外, @Transactional 注解应该只被应用到 public 方法上,这是由 Spring AOP 的本质决定的。如果你在 protected、private 或者默认可见性的方法上使用 @Transactional 注解,这将被忽略,也不会抛出任何异常。

默认情况下,只有来自外部的方法调用才会被AOP代理捕获,也就是,类内部方法调用本类内部的其他方法并不会引起事务行为,即使被调用方法使用@Transactional注解进行修饰。

@Transactional(readOnly = true)
public class DefaultFooService implements FooService {

   public Foo getFoo(String fooName) {
     // do something
   }

   // these settings have precedence for this method
   //方法上注解属性会覆盖类注解上的相同属性
   @Transactional(readOnly = false, propagation=
   Propagation.REQUIRES_NEW)
   public void updateFoo(Foo foo) {
     // do something
   }
 }

那么我们的问题就是如果使用@Transactional注解,将事务交给Spring处理的话,因为@Transactional默认设置为回滚,无论如何设置rollbackFor、noRollbackFor都会将事务回滚。但是代码执行的时候,似乎SQL语句没有执行回滚就结束了。所以接抛出该异常。
解决方法是从entityManager中得到EntityManagerFactory再创建一个新的EntityManager,然后开始执行事务:

@PersistenceContext
private EntityManager entityManager;

/**
 * 获取 entityManager 
 * @return the entityManager
 */
public EntityManager getEntityManager()
{
    return entityManager;
}

/**
 * 设置 entityManager 
 * @param entityManager the entityManager to set
 */
public void setEntityManager(EntityManager entityManager)
{
    this.entityManager = entityManager;
}

private int execute(String sql,EntityManager em) 
{
    EntityManager em = getEntityManager().getEntityManagerFactory().createEntityManager();
    em.getTransaction().begin();
    .......
    em.getTransaction().commit();
    return 1;
}

同时还能解决:javax.persistence.TransactionRequiredException: Executing an update/delete query异常,因为此处新建了一个事务处理。而该异常是没有事务处理Spring抛出来的异常,一举两得!

### Spring Framework 中 Transaction Marked as RollbackOnly 的异常解决方案 在 Spring 框架中,当事务被标记为 `rollback-only` 时,通常是由于某种原因导致事务无法正常提交。以下是关于此问题的原因分析以及对应的解决方案。 #### 原因分析 1. **显式的回滚请求** 开发者可能在代码中调用了 `TransactionAspectSupport.currentTransactionStatus().setRollbackOnly()` 方法,这会直接将当前事务标记为只允许回滚的状态[^1]。 2. **未捕获的异常** 在声明式事务管理中,如果某个方法抛出了受控或非受控异常,并且这些异常没有被捕获和处理,则默认情况下,Spring 会将事务标记为 `rollback-only`[^3]。 3. **嵌套事务的影响** 如果存在多个嵌套事务,其中一个子事务发生了错误并被标记为 `rollback-only`,那么父事务也会受到波及,最终整个事务链都会被回滚[^4]。 4. **数据库约束冲突** 数据库级别的约束(如外键约束、唯一性约束等)违反也可能导致事务失败,并将其标记为 `rollback-only`[^2]。 --- #### 解决方案 为了有效解决 `Transaction marked as rollbackOnly` 的问题,可以从以下几个方面入手: ##### 1. **检查异常传播路径** - 确保所有的业务逻辑都对可能出现的异常进行了合理的捕获和处理。 - 使用 AOP 或日志工具跟踪事务过程中发生的异常,定位具体位置及其成因。 ##### 2. **调整事务配置** - 修改事务的 `propagation` 和 `isolation` 属性以适应具体的业务需求。例如,可以尝试将传播行为设置为 `REQUIRES_NEW` 来隔离不同部分之间的相互影响。 ```java @Transactional(propagation = Propagation.REQUIRES_NEW) public void someMethod() { // Business logic here } ``` ##### 3. **合理设计事务边界** - 尽量缩小单个事务的作用范围,避免过多的操作集中在一个事务内完成。 - 对于复杂的业务流程,考虑拆分为多个独立的小型事务分别执行。 ##### 4. **验证数据库状态** - 检查是否存在违反数据库约束的情况,修正相关数据或更新表结构使其符合实际需求。 - 定期清理无用的历史记录,释放存储空间,降低死锁风险。 ##### 5. **调试与测试** - 添加详细的日志输出以便观察事务的实际运行轨迹。 - 构建单元测试覆盖各种潜在场景,提前发现隐患所在。 --- ### 示例代码 以下是一个简单的例子展示如何通过编程手段控制事务行为: ```java @Service public class MyService { @Autowired private SomeRepository repository; @Transactional(rollbackFor = Exception.class) public void performOperation() throws CustomBusinessException { try { // Step 1: Perform database operations repository.save(new Entity()); // Simulate an error condition if (someConditionFails()) { throw new CustomBusinessException("Custom failure occurred"); } // Continue with other steps... } catch (CustomBusinessException e) { log.error("Error during operation", e); throw e; // Re-throw to trigger rollback } } private boolean someConditionFails() { return true; // Replace with actual business logic check } } ``` 在此示例中,我们定义了一个自定义异常类 `CustomBusinessException` 并指定了它作为触发回滚的条件之一。这样即使遇到意外情况也能确保一致性不受破坏。 --- ###
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

chemyoo

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值