mybatis事务隔离级别（mybatis实现插入操作，框架默认事务自动提交是关闭的，为什么我没commit，数据就进库了）

本文目录

• mybatis实现插入操作，框架默认事务自动提交是关闭的，为什么我没commit，数据就进库了
• spring mybatis 防止同时update
• SpringBoot进阶之事务管理及并发问题

mybatis实现插入操作，框架默认事务自动提交是关闭的，为什么我没commit，数据就进库了

我今天也遇到了和楼主一样的问题，检查了很久一直不知道是什么问题，后来终于在一篇博客中发现了数据库引擎和事务有关，然后我就去mysql中将数据表的引擎改成了InnoDB，然后就成功了。

spring mybatis 防止同时update

需要进行排他处理，数据库里需要一个最后更新时间的字段，每次更新的时候更新该字段

修改操作的时候，需要拿到这条数据的最后更新时间，hidden在画面中，提交的时候，这个最后更新时间再去后台比较，如果不一样，那么说明之间有人改过，这时候给前台提示错误：【数据被其他用户修改，请重新进入该画面，再进行修改操作】

SpringBoot进阶之事务管理及并发问题

大家好，一直以来我都本着用最通俗的话理解核心的知识点, 我认为所有的难点都离不开 「基础知识」 的铺垫。目前正在出一个 SpringBoot 长期系列教程，从入门到进阶, 篇幅会较多~

「大佬可以绕过 ~」

如果你是一路看过来的，很高兴你能够耐心看完。之前带大家学了 Springboot 基础部分，对基本的使用有了初步的认识, 接下来的几期内容将会带大家进阶使用，会先讲解基础 中间件 的使用和一些场景的应用，或许这些技术你听说过，没看过也没关系，我会带大家一步一步的入门，耐心看完你一定会有 收获 ~

上期带大家学习了 SpringBoot 中如何去拦截请求, 本期将带大家学习 MyBatis 中如何进行 事务管理 ，同样的，我们集成到 Springboot 中。最近github可能会被墙，所以我把源码放到了国内gitee上,本节我们依然使用上期的代码

我们先了解一下它的基本概念。其实 事务 它不仅是在这里我们提到的 mybatis ,其实它在数据库中也是存在的。 事务 我们从字面意思理解，它好比烤面包，经过一些列的步骤之后，最终提供给客户完整的面包，也就是说中间出现差错，就得回退。可能举这个例子不大合适，再举一个我们业务中的场景吧。用户购买一个商品，首先下单，下完单之后进行支付，支付成功后订单为支付成功状态，跳转成功页，这一系列操作就是一个事务，要么成功要么失败。

在通过上面的例子有了大概了解之后，我们再看看它的基本概念。

下面带大家看看 sql 如何执行事务操作。下面举个例子比较一下

没有事务操作的时候:

以之前的场景给大家举例, 用户支付减少余额 并改订单状态为成功。 当我们的程序执行了上边的两条 sql ，大家觉得有问题吗？这肯定得出事，这不得被人薅死。虽然语句没报错，但是逻辑错了，为啥 因为余额变成负数了，这不是没钱白嫖,还指望用户给你冲上吗。然后订单还给成功了，如果遇到并发大的时候，这得多少钱，发还是不发货呢？告诉用户系统问题？老板看了得哭死。

所以不管是程序上的错误(sql执行错误),还是逻辑上的错误都不能进行下一步操作,所以事务显的尤为重要。那么 sql 怎么提交事务呢?

上边只是给大家举个例子，生成中我们还得用 mybatis 去操作。

在 SpringBoot 中执行事务非常简单,首先要开启事务 @EnableTransactionManagement ,在启动类上加上:

添加控制器方法:

我们访问 ***隐藏网址*** , 发现数据库并没有产生新纪录和更新记录， @Transactional(rollbackFor = Exception.class) 表示开启一个事务，当捕获到 Exception 异常就进行回滚。把 name 换掉会发现，执行成功了。

执行失败的时候:

那有没有 手动 去执行回滚操作的呢？有时候，我们总不能靠异常来判断，需要通过逻辑判断:

上边的方法 TransactionAspectSupport.currentTransactionStatus().setRollbackOnly(); 就是干这个的。

其实本节到这里差不多就结束了，给大家多讲一点, 其实这一块内容理论知识点还是比较多多的，这也是面试比较喜欢问的，因为这里真就靠大家自己去理解和学习了，写代码谁都会，但是讲出来，不一定每个人都讲的好和清楚，因为每个人的理解和认知不一样。

有时候，客户反馈有 bug ,反馈到你这边，你可能会说，我这都是好的。因为我们是本地的，不是跑在线上的，本地就你自己完，所以觉得没啥问题。但线上是很多用户在使用，当多用户使用的时候就会产生并发问题,所以也就是在接口测试的时候为什么要进行一下测试环境的压测，合格后上线。

那么在并发大的时候，我们数据库可能会产生什么问题呢？

好，我们一个一个讲，首先说说什么是丢失更新？

一个事务覆盖另一个事务已提交的更新数据叫丢失更新。这里提到过它存在两种丢失情况,为了让大家能够更加直观的感受，我以存钱和取钱为例讲一下。

首先说说第一种丢失情况

先分配一下角色，事务A,事务B,账户C。 首先A对C进行账户查询，余额为5000，B对A查询，余额为5000，此时余额一样没啥问题。紧接着B对C进行存钱操作，存了1000， 存完B提交事务。而此时A呢，正对着C进行取钱，取了1000， 它也提交了事务。那么问一下大家， C还有多少钱?

最后A查了一下账户，发现只有4000， 发现少了1000。

下边我们把压力给到A这边,第二种其实跟上边是反过来，情况是怎么样的呢？首先A,B跟之前一样，查了下C，余额为5000。此时，A对C进行取钱操作，取了1000，然后提交事务,B呢对A进行存钱操作,存了1000，提交事务。最后B一查，发现账户有6000, C开心极了， 多了1000

上边这两种情况都属于丢失更新的情况

一个事务读取到另一个事务还没提交的数据叫脏读。我们还以上边的为例:

这个稍微好理解一点,事务A和B, 事务A对C进行取钱操作，取了1000, 余额还剩 4000, 此时B呢对C进行查询操作，读到余额为4000。这时产生问题了，因为A现在还是一个未提交的事务，A对账户C取钱操作进行了 回滚 , 紧接着存了1000, 然后进行了 事务提交 , 此时余额为6000。而我们的B读到的数据是4000,所以这就是 脏读

一个事务先后读到另一个事务提交之前的数据和已提交的更新数据。同样的以上边为例，这个大家可能不好理解，下面好好分析一下:

首先事务A和B， A先查询C余额还有 5000， B 查询C,余额还有5000, 紧接着A对C执行取钱操作，取了1000, 提交事务, 此时B执行查询操作，发现C只有4000了。你可能想，这没问题啊，取了1000还有4000，没毛病啊。没问题吗？重复读了两次，结果不一致，这肯定是有问题的。

事务在操作过程中进行两次查询，第二次查询的结果包含了第一次查询中未出现的数据或者缺少了第一次查询中出现的数据。这有点抽象,同样的，还以上边为例

事务A和B，B查询C，余额5000， A注销了C,提交了事务，此时B又去查询C, 发现C没了，B事务查询两次，结果确不一致，跟产生了幻觉一样，刚刚还在的，这会没了。

通过上边的几个例子，带大家认识了，并发中可能产生的事务问题，下边给大家总结一下事务的特点, 事务有4个特性，被称为 ACID

下边就给大家讲讲这几个特性:

事务处理结束后，对数据的修改就是永久的，即便系统故障也不会丢失。

数据库允许多个并发事务同时对其数据进行读写和修改的能力，隔离性可以防止多个事务并发执行时由于交叉执行而导致数据的不一致。

在事务开始之前和事务结束以后，数据库的完整性没有被破坏

一个事务（transaction）中的所有操作，要么全部完成，要么全部不完成

隔离级别就不给大家讲了，这不是本节的重点内容。本节的重点是大家要学会在 SpringBoot 中如何去执行 事务操作 ,如果你对上边提到的一些概念性的东西还不能理解，也没关系，等以后回过头来看看也许就明白了，做个简单的了解。

有时候我们的系统需要对用户进行区分，也就是不同的用户角色访问不同的资源，比如管理员可以访问后台，而普通用户只能访问前台的页面，再或者只有登录的用户才能访问特定功能，高级管理员可以掌管大局，普通的管理员只能查看某一个菜单。这就是涉及到权限问题了，几乎所有的系统都需要权限管理，这样能保证系统资源的安全性。下期将会带大家学习 Shiro权限 框架, 它是一个轻量级框架，但它的功能确不小, 我会从入门到进阶讲起, 会分为多期去讲。

下期见，关注我，不迷路~