在这个工程中,定义一个名为User
的实体:
@Entity
@Data
@NoArgsConstructor
public class User {@Id@GeneratedValueprivate 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
。
源码解析
要想了解,这其中到底发生了什么,跟踪源码是最好的方式。那么源码从哪里开始看呢?从异常日志中找线索吧。
从异常栈中找到最近的一个错误,点开看看。
错误行数在532行tx.commit()
,习惯性的加上断点,这样下一次进来的时候可以看看当前情况下的各种参数情况。
同时看到下面还有个catch,既然532行出错了,那这里肯定会进,所以也加个端点,到时候可以进去看看。
执行程序,调用一下test4,执行到532行,然后进入下一步,看看会到哪里?
这个时候,会进入到org.hibernate.engine.transaction.internal.TransactionImpl
,具体位置如下:
还是习惯性的,在下面两行重要位置加上断点,以便下次可以快速到这里。
继续按上看的步骤尝试下去,可以来到下图的位置:
可以看到校验异常是从271行出来的,结合278行和280行,是不是清楚这里回滚的原因了呢?
为什么加了@Transactional注解,事务没有回滚?
@Transactional
注解不生效,是Spring使用者非常常见的一类问题,上面我们讲了一种,其他还有一些可能的原因,这里作为扩展阅读一并列出。
如果你当前碰到的原因不是上面的情况,那就看看下面这几种情况是否存在:
1.@Transactional
注解修饰的函数中catch
了异常,并没有往方法外抛。不过,也有一写复杂场景可能不一样,比如我这里出的四个题中的test4:我来出个题:这个事务会不会回滚?
2.@Transactional
注解修饰的函数不是public
类型
3.异常类型错误,如果有通过rollbackFor指定回滚的异常类型,那么抛出的异常与指定的是否一致。
4.数据源没有配置事务管理器
5.在一个类中调用自己的方法。建议分开写,互相调用。
6.对应数据库使用的存储引擎不支持事务,比如:MyISAM。