JPA事务示例分析

最新推荐文章于 2024-08-14 10:40:48 发布

gqltt

最新推荐文章于 2024-08-14 10:40:48 发布

阅读量538

点赞数

分类专栏：数据库原理文章标签：数据库事务

本文链接：https://blog.csdn.net/listeningsea/article/details/118410056

版权

数据库原理专栏收录该内容

9 篇文章 0 订阅

订阅专栏

在这个工程中，定义一个名为User的实体：

@Entity
@Data
@NoArgsConstructor
public class User {

    @Id
    @GeneratedValue
    private Long id;

    @Size(max = 5)
    private String name;
    @Max(50)
    private Integer age;

    public User(String name, Integer age) {
        this.name = name;
        this.age = age;
    }

}

这里name设置了长度为5，这样可以通过insert语句中的name超长，让其抛出异常，从而可以测试事务的触发。

另外工程中还包含了Spring Data Jpa的数据访问对象UserRepository，用来实现对User实体的数据操作，这里就不放具体代码了。

问题来了

这里数据库采用MySQL 5.7，存储引擎为InnoDB，使用默认事务级别。

下面来调整下这四个问题吧：

问题一：test1会不会回滚？-- 回滚

@Transactional
public void test1() {
    userRepository.save(new User("AAA", 10));
    throw new RuntimeException();
}

问题二：test2会不会回滚？-- 不回滚

@Transactional
public void test2() {
    userRepository.save(new User("AAA", 10));
    try {
        throw new RuntimeException();
    } catch (Exception e) {
        log.error("异常捕获：", e);
    }
}

问题三：test3会不会回滚？（第二句插入name超长）-- 回滚

@Transactional
public void test3() {
    userRepository.save(new User("AAA", 10));
    userRepository.save(new User("1234567890", 20));
}

问题四：test4会不会回滚？（第二句插入name超长）-- 回滚

@Transactional
public void test4() {
    userRepository.save(new User("AAA", 10));
    try {
        userRepository.save(new User("1234567890", 20));
    } catch (Exception e) {
        log.error("异常捕获：", e);
    }
}

为什么写了catch，还会回滚

先来看看执行时候报的异常：

javax.validation.ConstraintViolationException: Validation failed for classes [com.didispace.chapter310.User] during persist time for groups [javax.validation.groups.Default, ]
List of constraint violations:[
 ConstraintViolationImpl{interpolatedMessage='个数必须在0和5之间', propertyPath=name, rootBeanClass=class com.didispace.chapter310.User, messageTemplate='{javax.validation.constraints.Size.message}'}
]
 at org.hibernate.cfg.beanvalidation.BeanValidationEventListener.validate(BeanValidationEventListener.java:140) ~[hibernate-core-5.3.7.Final.jar:5.3.7.Final]
 at org.hibernate.cfg.beanvalidation.BeanValidationEventListener.onPreInsert(BeanValidationEventListener.java:80) ~[hibernate-core-5.3.7.Final.jar:5.3.7.Final]
 at org.hibernate.action.internal.EntityInsertAction.preInsert(EntityInsertAction.java:209) ~[hibernate-core-5.3.7.Final.jar:5.3.7.Final]
 at org.hibernate.action.internal.EntityInsertAction.execute(EntityInsertAction.java:83) ~[hibernate-core-5.3.7.Final.jar:5.3.7.Final]
 at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:604) ~[hibernate-core-5.3.7.Final.jar:5.3.7.Final]
 at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:478) ~[hibernate-core-5.3.7.Final.jar:5.3.7.Final]
 at org.hibernate.event.internal.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:356) ~[hibernate-core-5.3.7.Final.jar:5.3.7.Final]
 at org.hibernate.event.internal.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:39) ~[hibernate-core-5.3.7.Final.jar:5.3.7.Final]
 at org.hibernate.internal.SessionImpl.doFlush(SessionImpl.java:1454) ~[hibernate-core-5.3.7.Final.jar:5.3.7.Final]
 at org.hibernate.internal.SessionImpl.managedFlush(SessionImpl.java:511) ~[hibernate-core-5.3.7.Final.jar:5.3.7.Final]
 at org.hibernate.internal.SessionImpl.flushBeforeTransactionCompletion(SessionImpl.java:3283) ~[hibernate-core-5.3.7.Final.jar:5.3.7.Final]
 at org.hibernate.internal.SessionImpl.beforeTransactionCompletion(SessionImpl.java:2479) ~[hibernate-core-5.3.7.Final.jar:5.3.7.Final]
 at org.hibernate.engine.jdbc.internal.JdbcCoordinatorImpl.beforeTransactionCompletion(JdbcCoordinatorImpl.java:473) ~[hibernate-core-5.3.7.Final.jar:5.3.7.Final]
 at org.hibernate.resource.transaction.backend.jdbc.internal.JdbcResourceLocalTransactionCoordinatorImpl.beforeCompletionCallback(JdbcResourceLocalTransactionCoordinatorImpl.java:178) ~[hibernate-core-5.3.7.Final.jar:5.3.7.Final]
 at org.hibernate.resource.transaction.backend.jdbc.internal.JdbcResourceLocalTransactionCoordinatorImpl.access$300(JdbcResourceLocalTransactionCoordinatorImpl.java:39) ~[hibernate-core-5.3.7.Final.jar:5.3.7.Final]
 at org.hibernate.resource.transaction.backend.jdbc.internal.JdbcResourceLocalTransactionCoordinatorImpl$TransactionDriverControlImpl.commit(JdbcResourceLocalTransactionCoordinatorImpl.java:271) ~[hibernate-core-5.3.7.Final.jar:5.3.7.Final]
 at org.hibernate.engine.transaction.internal.TransactionImpl.commit(TransactionImpl.java:98) ~[hibernate-core-5.3.7.Final.jar:5.3.7.Final]

这个异常是这个回滚的关键。这个异常javax.validation.ConstraintViolationException是哪里的呢？还记得以前说的JSR 303不？对的，是Bean Validation中的异常。

有的读者说这个不是RuntimeException，所以不会回滚。很显然，这类判断的都没有实际尝试一下，只要点开源码可以马上发现，这个异常就是属于RunTimeException的。

实际上，之所以会回滚，与这里使用Spring Data JPA以及Hibernate Validator有直接关系。从JPA 2.0开始，就默认支持了这些Bean Validation的实现，它提供了实体生命周期中pre-persist, pre-update,pre-remove三个事件发生时来执行校验的功能。而在校验的时候，当校验失败，抛出javax.validation.ConstraintViolationException时，当前事务就会被标记为rollback。