Transactional失效场景介绍
第一种
Transactional注解标注方法修饰符为非public时，@Transactional注解将会不起作用。例如以下代码。
定义一个错误的@Transactional标注实现，修饰一个默认访问符的方法
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
|
/**
* @author zhoujy
**/
@Component
public class TestServiceImpl {
@Resource
TestMapper testMapper;
@Transactional
void insertTestWrongModifier() {
int re = testMapper.insert(new Test(10,20,30));
if (re > 0) {
throw new NeedToInterceptException("need intercept");
}
testMapper.insert(new Test(210,20,30));
}
}
|
在同一个包内，新建调用对象，进行访问。
1
2
3
4
5
6
7
8
9
|
@Component
public class InvokcationService {
@Resource
private TestServiceImpl testService;
public void invokeInsertTestWrongModifier(){
//调用@Transactional标注的默认访问符方法
testService.insertTestWrongModifier();
}
}
|
测试用例
1
2
3
4
5
6
7
8
9
10
11
|
@RunWith(SpringRunner.class)
@SpringBootTest
public class DemoApplicationTests {
@Resource
InvokcationService invokcationService;
@Test
public void testInvoke(){
invokcationService.invokeInsertTestWrongModifier();
}
}
|
以上的访问方式，导致事务没开启，因此在方法抛出异常时，testMapper.insert(new Test(10,20,30));操作不会进行回滚。如果TestServiceImpl#insertTestWrongModifier方法改为public的话将会正常开启事务，testMapper.insert(new Test(10,20,30));将会进行回滚。
第二种
在类内部调用调用类内部@Transactional标注的方法。这种情况下也会导致事务不开启。示例代码如下。
设置一个内部调用
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
|
/**
* @author zhoujy
**/
@Component
public class TestServiceImpl implements TestService {
@Resource
TestMapper testMapper;
@Transactional
public void insertTestInnerInvoke() {
//正常public修饰符的事务方法
int re = testMapper.insert(new Test(10,20,30));
if (re > 0) {
throw new NeedToInterceptException("need intercept");
}
testMapper.insert(new Test(210,20,30));
}
public void testInnerInvoke(){
//类内部调用@Transactional标注的方法。
insertTestInnerInvoke();
}
}
|
测试用例。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
|
@RunWith(SpringRunner.class)
@SpringBootTest
public class DemoApplicationTests {
@Resource
TestServiceImpl testService;
/**
* 测试内部调用@Transactional标注方法
*/
@Test
public void testInnerInvoke(){
//测试外部调用事务方法是否正常
//testService.insertTestInnerInvoke();
//测试内部调用事务方法是否正常
testService.testInnerInvoke();
}
}
|
上面就是使用的测试代码，运行测试知道，外部调用事务方法能够征程开启事务，testMapper.insert(new Test(10,20,30))操作将会被回滚；
然后运行另外一个测试用例，调用一个方法在类内部调用内部被@Transactional标注的事务方法，运行结果是事务不会正常开启，testMapper.insert(new Test(10,20,30))操作将会保存到数据库不会进行回滚。
第三种
事务方法内部捕捉了异常，没有抛出新的异常，导致事务操作不会进行回滚。示例代码如下。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
|
/**
* @author zhoujy
**/
@Component
public class TestServiceImpl implements TestService {
@Resource
TestMapper testMapper;
@Transactional
public void insertTestCatchException() {
try {
int re = testMapper.insert(new Test(10,20,30));
if (re > 0) {
//运行期间抛异常
throw new NeedToInterceptException("need intercept");
}
testMapper.insert(new Test(210,20,30));
}catch (Exception e){
System.out.println("i catch exception");
}
}
}
|
测试用例代码如下。
1
2
3
4
5
6
7
8
9
10
11
12
|
@RunWith(SpringRunner.class)
@SpringBootTest
public class DemoApplicationTests {
@Resource
TestServiceImpl testService;
@Test
public void testCatchException(){
testService.insertTestCatchException();
}
}
|
运行测试用例发现，虽然抛出异常，但是异常被捕捉了，没有抛出到方法 外， testMapper.insert(new Test(210,20,30))操作并没有回滚。
以上三种就是@Transactional注解不起作用，@Transactional注解失效的主要原因。下面结合spring中对于@Transactional的注解实现源码分析为何导致@Transactional注解不起作用。
在这个工程中，定义一个名为User的实体：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
|
@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会不会回滚？
1
2
3
4
5
|
@Transactional
public void test1() {
userRepository.save(new User("AAA", 10));
throw new RuntimeException();
}
|
问题二：test2会不会回滚？（第二句插入name超长）
1
2
3
4
5
|
@Transactional
public void test3() {
userRepository.save(new User("BBB", 10));
userRepository.save(new User("123456", 20));
}
|
问题三：test3会不会回滚？（第二句插入name超长）
1
2
3
4
5
6
7
8
9
|
@Transactional
public void test4() {
userRepository.save(new User("BBB", 10));
try {
userRepository.save(new User("123456", 20));
} catch (Exception e) {
log.error("异常捕获：", e);
}
}
|
答案是这三种都会回滚。
第四种
旧版本MyISAM引擎导致不支持事务，故无法正确回滚
所以，如果你的事务没有生效，那么可以看看创建的表，是不是使用了MyISAM存储引擎，如果是的话，那就是这个原因了！
第五种
数据源没有配置事务管理器
第六种
异常类型错误，如果有通过rollbackFor指定回滚的异常类型，那么抛出的异常与指定的是否一致。
@Transactional注解不起作用原理分析
第一种
@Transactional注解标注方法修饰符为非public时，@Transactional注解将会不起作用。这里分析 的原因是，@Transactional是基于动态代理实现的，@Transactional注解实现原理中分析了实现方法，在bean初始化过程中，对含有@Transactional标注的bean实例创建代理对象，这里就存在一个spring扫描@Transactional注解信息的过程，不幸的是源码中体现，标注@Transactional的方法如果修饰符不是public，那么就默认方法的@Transactional信息为空，那么将不会对bean进行代理对象创建或者不会对方法进行代理调用
@Transactional注解实现原理中，介绍了如何判定一个bean是否创建代理对象，大概逻辑是。根据spring创建好一个aop切点BeanFactoryTransactionAttributeSourceAdvisor实例，遍历当前bean的class的方法对象，判断方法上面的注解信息是否包含@Transactional，如果bean任何一个方法包含@Transactional注解信息，那么就是适配这个BeanFactoryTransactionAttributeSourceAdvisor切点。则需要创建代理对象，然后代理逻辑为我们管理事务开闭逻辑。
spring源码中，在拦截bean的创建过程，寻找bean适配的切点时，运用到下面的方法，目的就是寻找方法上面的@Transactional信息，如果有，就表示切点BeanFactoryTransactionAttributeSourceAdvisor能够应用（canApply）到bean中，
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
|
AopUtils#canApply(org.springframework.aop.Pointcut, java.lang.Class<?>, boolean)
public static boolean canApply(Pointcut pc, Class<?> targetClass, boolean hasIntroductions) {
Assert.notNull(pc, "Pointcut must not be null");
if (!pc.getClassFilter().matches(targetClass)) {
return false;
}
MethodMatcher methodMatcher = pc.getMethodMatcher();
if (methodMatcher == MethodMatcher.TRUE) {
// No need to iterate the methods if we're matching any method anyway...
return true;
}
IntroductionAwareMethodMatcher introductionAwareMethodMatcher = null;
if (methodMatcher instanceof IntroductionAwareMethodMatcher) {
introductionAwareMethodMatcher = (IntroductionAwareMethodMatcher) methodMatcher;
}
//遍历class的方法对象
Set<Class<?>> classes = new LinkedHashSet<Class<?>>(ClassUtils.getAllInterfacesForClassAsSet(targetClass));
classes.add(targetClass);
for (Class<?> clazz : classes) {
Method[] methods = ReflectionUtils.getAllDeclaredMethods(clazz);
for (Method method : methods) {
if ((introductionAwareMethodMatcher != null &&
introductionAwareMethodMatcher.matches(method, targetClass, hasIntroductions)) ||
//适配查询方法上的@Transactional注解信息
methodMatcher.matches(method, targetClass)) {
return true;
}
}
}
return false;
}
|
我们可以在上面的方法打断点，一步一步调试跟踪代码，最终上面的代码还会调用如下方法来判断。在下面的方法上断点，回头看看方法调用堆栈也是不错的方式跟踪。推荐：Java面试练题宝典
1
|
AbstractFallbackTransactionAttributeSource#getTransactionAttribute
|
AbstractFallbackTransactionAttributeSource#computeTransactionAttribute
1
2
3
4
5
6
7
8
|
protected TransactionAttribute computeTransactionAttribute(Method method, Class<?> targetClass) {
// Don't allow no-public methods as required.
//非public 方法，返回@Transactional信息一律是null
if (allowPublicMethodsOnly() && !Modifier.isPublic(method.getModifiers())) {
return null;
}
//后面省略.......
}
|
不创建代理对象
所以，如果所有方法上的修饰符都是非public的时候，那么将不会创建代理对象。以一开始的测试代码为例，如果正常的修饰符的testService是下面图片中的，经过cglib创建的代理对象。
如果class中的方法都是非public的那么将不是代理对象。
不进行代理调用
考虑一种情况，如下面代码所示。两个方法都被@Transactional注解标注，但是一个有public修饰符一个没有，那么这种情况我们可以预见的话，一定会创建代理对象，因为至少有一个public修饰符的@Transactional注解标注方法。
创建了代理对象，insertTestWrongModifier就会开启事务吗？答案是不会。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
|
/**
* @author zhoujy
**/
@Component
public class TestServiceImpl implements TestService {
@Resource
TestMapper testMapper;
@Override
@Transactional
public void insertTest() {
int re = testMapper.insert(new Test(10,20,30));
if (re > 0) {
throw new NeedToInterceptException("need intercept");
}
testMapper.insert(new Test(210,20,30));
}
@Transactional
void insertTestWrongModifier() {
int re = testMapper.insert(new Test(10,20,30));
if (re > 0) {
throw new NeedToInterceptException("need intercept");
}
testMapper.insert(new Test(210,20,30));
}
}
|
原因是在动态代理对象进行代理逻辑调用时，在cglib创建的代理对象的拦截函数中CglibAopProxy.DynamicAdvisedInterceptor#intercept，有一个逻辑如下，目的是获取当前被代理对象的当前需要执行的method适配的aop逻辑。
1
|
List<Object> chain = this.advised.getInterceptorsAndDynamicInterceptionAdvice(method, targetClass);
|
而针对@Transactional注解查找aop逻辑过程，相似地，也是执行一次
1
|
AbstractFallbackTransactionAttributeSource#getTransactionAttribute
|
AbstractFallbackTransactionAttributeSource#computeTransactionAttribute
也就是说还需要找一个方法上的@Transactional注解信息，没有的话就不执行代理@Transactional对应的代理逻辑，直接执行方法。没有了@Transactional注解代理逻辑，就无法开启事务，这也是上一篇已经讲到的。
第二种
在类内部调用调用类内部@Transactional标注的方法。这种情况下也会导致事务不开启。
经过对第一种的详细分析，对这种情况为何不开启事务管理，原因应该也能猜到；
既然事务管理是基于动态代理对象的代理逻辑实现的，那么如果在类内部调用类内部的事务方法，这个调用事务方法的过程并不是通过代理对象来调用的，而是直接通过this对象来调用方法，绕过的代理对象，肯定就是没有代理逻辑了。
其实我们可以这样玩，内部调用也能实现开启事务，代码如下。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
|
/**
* @author zhoujy
**/
@Component
public class TestServiceImpl implements TestService {
@Resource
TestMapper testMapper;
@Resource
TestServiceImpl testServiceImpl;
@Transactional
public void insertTestInnerInvoke() {
int re = testMapper.insert(new Test(10,20,30));
if (re > 0) {
throw new NeedToInterceptException("need intercept");
}
testMapper.insert(new Test(210,20,30));
}
public void testInnerInvoke(){
//内部调用事务方法
testServiceImpl.insertTestInnerInvoke();
}
}
|
上面就是使用了代理对象进行事务调用，所以能够开启事务管理，但是实际操作中，没人会闲的蛋疼这样子玩~
实在碰到业务需要，建议分开写，互相调用。
第三种
事务方法内部捕捉了异常，没有抛出新的异常，导致事务操作不会进行回滚。
这种的话，可能我们比较常见，问题就出在代理逻辑中，我们先看看源码里卖弄动态代理逻辑是如何为我们管理事务的。
1
|
TransactionAspectSupport#invokeWithinTransaction
|
代码如下。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
|
protected Object invokeWithinTransaction(Method method, Class<?> targetClass, final InvocationCallback invocation)
throws Throwable {
// If the transaction attribute is null, the method is non-transactional.
final TransactionAttribute txAttr = getTransactionAttributeSource().getTransactionAttribute(method, targetClass);
final PlatformTransactionManager tm = determineTransactionManager(txAttr);
final String joinpointIdentification = methodIdentification(method, targetClass);
if (txAttr == null || !(tm instanceof CallbackPreferringPlatformTransactionManager)) {
// Standard transaction demarcation with getTransaction and commit/rollback calls.
//开启事务
TransactionInfo txInfo = createTransactionIfNecessary(tm, txAttr, joinpointIdentification);
Object retVal = null;
try {
// This is an around advice: Invoke the next interceptor in the chain.
// This will normally result in a target object being invoked.
//反射调用业务方法
retVal = invocation.proceedWithInvocation();
}
catch (Throwable ex) {
// target invocation exception
//异常时，在catch逻辑中回滚事务
completeTransactionAfterThrowing(txInfo, ex);
throw ex;
}
finally {
cleanupTransactionInfo(txInfo);
}
//提交事务
commitTransactionAfterReturning(txInfo);
return retVal;
}
else {
//....................
}
}
|
所以看了上面的代码就一目了然了，事务想要回滚，必须能够在这里捕捉到异常才行，如果异常中途被捕捉掉，那么事务将不会回滚。
解释三种情况异常会回滚
一二不难理解，由于没有被Catch，故捕捉不到，案例三有些特殊
为什么没回滚
先来说说，那些写了代码验证"不会回滚“的情况，把这些错误答案的原因先说清楚，然后再细说test4会回滚的情况。
根据这两天读者给我的案例或者描述清楚的一些情况，归结了一下，大家写的验证代码之所以不会回滚，主要有以下三个原因：
- 没有按照我题目开头说的，采用InnoDB存储引擎，用了MyISAM，不支持事务，自然不会复现。
- 没用按照我题目开头说的，采用JPA和JSR 303校验注解，比如：用了MyBaits，所以自然也不会复现。
- 定义事务的函数不是public类型，这个基础用法就不对了，事务本身就没生效
归家一下出现这些疑问的原因：没审题和事务基础掌握不牢导致。关于事务基础使用的一些常见注意点，之前写过一篇文章，如果觉得这方面知识还不扎实的，建议读一读：《为什么加了@Transactional注解，事务没有回滚？》(https://blog.didispace.com/transactional-not-rollback/)
为什么写了catch，还会回滚
先来看看执行时候报的异常：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
|
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行，是不是清楚这里回滚的原因了呢？
小结
当我把上一篇问题推到很多地方之后，其实还是收到了不少负面的反馈，甚至还有说我误导读者，顺便问候了下我的祖宗。这些我就不跟爱喷的读者互杠了，我是一直都推崇碰到问题，尽量多深挖一些的学习方式。虽然有的时候出现问题，确实是由于不恰当的写法导致，但如果你没有理解这个错误的原因，本质还是对其底层逻辑不够了解。如果你能从问题中找到线索，并顺藤摸瓜地探究和思考，你能够收获到的东西，远比喷我来的强。
实践出真知，当你觉得困惑的时候，不如动手写一写，调一调，很多答案就能自然浮现！如果对于test3会回滚还不够理解的读者，那就跟着我上面的步骤，一步步尝试一下，可以观察的更深入一些，你对这部分逻辑的理解就更全面了。
返场 动手尝试一下
由于@Transactional注解的事务是通过切面来实现的，所以要通过源码去了解整个过程，可能还是会比较晕。
所以，这里教大家一个简单方法来理解这次test4的catch为什么没有捕获异常。
我们通过类似下面的方式，给test4多加一些日志信息和断点：
同时，记得也在上一篇说到的事务提交入口，也加上断点。
org.springframework.orm.jpa.JpaTransactionManager
然后尝试触发test4的执行，通过DEBUG，我们都可以观察到：
test4中我们加的断点，除了47行没进入，其他的一次性都执行完了。然后才进入了org.springframework.orm.jpa.JpaTransactionManager的doCommit方法。
所以，前文中我们跟踪的事务回滚所抛出的异常，其实是在test4中的try-catch块执行完之后才抛出的，所以内部的这个catch是无法捕获异常的，这里完全就是catch了个寂寞。
通过日志，我们也能观察到这样的执行顺序：
好了，通过这样来看，是不是要比之前有进一步的理解了呢？如果您还想更深入的了解事务的底层运行机制，一定要debug下源码，自己过一遍，理解会深刻哦！如果你没有得到跟我一样的结果，那更要找找原因，除了审题之外，再仔细跟踪下执行过程，这么做远比下面这样要得到更多收获哦~
第四种
在前文的描述中，我漏了一个细节，其实在示例代码中，与之前拿的基础例子在配置中有一个关键属性没有提到，就是下面这个配置：
1
|
spring.jpa.database-platform=org.hibernate.dialect.MySQL5InnoDBDialect
|
这里的spring.jpa.database-platform配置主要用来设置hibernate使用的方言。这里特地采用了MySQL5InnoDBDialect，主要为了保障在使用Spring Data JPA时候，Hibernate自动创建表的时候使用InnoDB存储引擎，不然就会以默认存储引擎MyISAM来建表，而MyISAM存储引擎是没有事务的。
修改数据库引擎即可
第五种
正确配置事务管理器
第六种
修改异常类型一致即可
总结了以上几种情况。
org.springframework.orm.jpa.JpaTransactionManager