事务回滚

关于事务回滚的概念我们之前在学习数据库的时候已经提到过了，这里我们再次强化一下记忆。所谓的事务回滚就是在执行多条SQL语句的时候，如果其中一条SQL出现了异常导致执行失败，则数据库的状态回滚到执行多条SQL语句之前的状态，就防止你执行的之后一次一次的添加脏数据。
其实这个也很好理解啊，因为SQL的执行是一种命令，你做了什么操作只要成功了就会直接更改数据库的状态，他不想是代码，你可以反复的一遍一遍的测试，不会对环境造成任何的影响，所以这里就出现了一个问题。
我们之前在测试业务层的时候，会调用DAO层的接口向数据库中写数据，那么这个过程我们写进去了就是写进去了，他就会保存在数据库中，那么如何在我们测试的时候制作测试，并不要真实的写入数据。这时候就需要我们的事务出场了，事务的概念并不局限于MySQL中的存储过程或者SQL脚本，你的Java方法中包含了多条SQL语句的执行那也算作是一个事务，那么我们直接不提交事务，他也就不会写入数据了。
那么我们就介绍一下如何在测试中控制事务的提交。

事务的提交

首先我们要搭建一个基础的环境，就是准备好DAO层和service层，并且在测试方法中调用service层的方法。

只需要创建Dao层和Service层即可，有基本的功能即可，需要注意的是我们这里需要有一个插入数据的SQL语句，这样我们才能测试事务的回滚。

先看一下现在的数据库中的状态，现在是没有任何的数据的空表，那么我们创建一个测试：

我们模拟一下对Service层的插入数据的过程，我们可以运行测试方法进行测试，也可以使用Mavne的test生命周期进行测试，只要最终能运行测试代码就可以：

这里我使用了Maven的test生命周期进行测试，然后他将我们的测试代码运行了一遍，我们看一下数据的现在的状态：

可以看到这里多出了一行数据，这个数据就是我们在测试的时候执行代码的时候持久化就去的一行数据，那么如何让我们在做测试的时候不出现这个数据呢，就需要我们添加一个新的注解，叫做@Transactional，这个注解的出现，就表示当前测试类，不提交事务。
这个注解是如何控制事务的提交的呢，是靠着另一个注解，@RollBack注解来控制事务的提交的。

当我们添加了@Tianscational注解的时候，他里面会调用一个@Rollback注解，这个注解就是控制事务是否提交的注解，默认值是true也就是提交事务，这时候数据就不能被写入数据，但是当值设置为false的时候，这时候即使有@Tianscational注解存在也依旧不能回滚事务，而是正常的写入数据。但是单独使用@Rollback注解是不起作用的。

自动主键自增在回滚状态下依然会增加

在测试的时候，即使在数据库中看到没有写入数据，但是依然会让自增主键增长，也就是说这时候SQL语句其实是执行成功的，只不过是没有写入数据而已，现在我们注掉@Transcational注解，再次执行测试看一下数据库中的数据：

执行测试代码之后，现在数据库中的数据只有两条，但是自增的id已经涨到了7，其实应该是依次增长的，我测试的时候出了点Bug删了几条，但是道理是一样的，就是我们虽然测试的时候没有写入数据，但是id自增还是发生了，这个要注意一下。