事务方法中使用truncate会发生什么

场景

在一个spring项目的事务方法中(使用@transactional注解):
首先执行一个delete语句;
然后执行一个truncate语句;
最后再执行一个insert语句;

问题:

为什么delete语句和truncate语句执行成功,但insert语句虽然执行了,却没有提交?

解释:

首先,在没有事务注解的方法中,一切与数据库的交互都是由mybatis处理的,
而mybatis默认是事务自动提交的,也就是每条sql语句执行完后会立即提交。

在添加事务注解后,应用与数据库的交互会由spring和mybatis共同处理(所以它们要共用同一个数据源):
spring管理事务,mybatis负责具体sql的执行。

那它们是如何协调的呢?
spring首先会在一开始创建连接开启事务,同时将连接放进当前线程(threadlocal);
mybatis执行sql语句时会从当前线程获取连接——这样就保证了spring和mybatis使用的是同一个连接;
mybatis执行sql后,会检查方法上是否有事务注解,如果有的话就不执行commit语句;
最后由spring执行commit。

这也就解释了一开始的问题:
执行完truncate后,当前事务已被提交(truncate虽然性能比delete好,但它是DDL语句,会触发事务提交),后续执行sql时,由于mybatis检测到事务注解所以不会提交
而spring此时早已把事务提交,也不会在方法结束时再一次提交了。

参考:https://www.cnblogs.com/Houz/p/11957908.html
https://www.cnblogs.com/guyaoblog/p/11421978.html

你可能感兴趣的:(web应用开发,mybatis,数据库,spring,java,mysql)