从一个小需求了解数据库的事务与传播属性

问题背景

         在上周的工作中,我拿到了这样的一个需求,大致就是在一个后台节点中新增一条数据,如果新增成功则会在另外一张表中也新增一条与其相关的数据。举个例子说明的话就是在一个视频网站中,你注册了一个用户,此时后台会获取你的注册信息(用户名与密码)并将你的信息保存在user表当中,与此同时,视频网站的主要收入来源是会员与充值等业务,因此在保存你信息的同时,又会在数据库当中记录你的账户余额,vip等级等(初始余额为0,初始vip等级也为0)。后面也应用这个用户会员的例子来讲解。

最初的构想与实现

        好,拿到这个需求我立马着手去实现这个需求,马上能想到的一个解决方案呢就是在一个controller当中,分别调用用户的service以及用户会员信息的service,这样不就大功告成了嘛,所以开始愉快的敲代码,首先是两个实体用户User与用户相关信息UserInfo,其中分别保存在user与user_info当中,代码如下:

User实体(用户名<主键>,密码)
UserInfo实体(用户名<主键>,会员等级,账户余额)

实体设计完成后,按照我们的思路在controller中分别调用两个service用于保存数据,首先保存用户数据,然后new出一个UserInfo的对象,将userName属性赋值所获取的User对象的name,然后初始化会员等级余额等信息并保存,主要代码如下:

controller层的主要代码实现

运用测试工具postman进行测试:

postman测试

结果成功返回了语气的“保存成功的”字符串,这时候再去数据库查看一下数据,看看是否生成了对应的数据。

user表中数据
user_info表中的数据

可以看到数据库中成功保存了传入的user数据并在user_info中添加了对应的账户余额,会员等级等数据,看到这里看似我们圆满完成了功能,但是可能对数据库事务有一点了解的同学就能发现这个代码有个重大的问题。

重大问题之前你应该了解的事务二三事

        在这之前我们先简单讲讲事务(有一定认识的同学可以跳过),事务其实就是指的是一组逻辑操作单元,具体点来说就是一组数据库操作,由于在项目中给service层加入了@Transactional注解开启了事务,所以每个service其实都能看作是一个事务(一般都在service层加入注解)。而事务存在的最大意义,就是在一组操作中的某一个操作出现了错误,事务中的其他操作都能进行回滚。其实这也就是如果不这样的话就破坏了平时所说的ACID(原子性、一致性、隔离性和持久性)属性(具体就不在这里赘述,有兴趣可以谷歌或者百度)。总之简单来说,就是事务能保证操作要么全部完成,要么全部不完成

重大的问题

        回到我们的代码上,看似功能已经完成了,那重大的问题是什么呢?有了上面的简单认识之后,我们说过因为@Transactional注解一般是加在service层,因此user的service可以看做一个事务,同时userInfo的service也可以看做是一个事务,所以在单独调用service对user和userinfo进行保存的时候,是可以实现异常回滚的。但是事务之间并没有设置相互的关系,因此userinfo的出错并不会导致user的回滚,这就好像用户登录你的视频网站之后,想要充值却发现看不到自己充值后的余额,明明开通了会员却看不到炫酷的会员图标和等级。这其实就是上面代码的重大问题。先测试一下看是不是真的会产生这样的问题。我们人为在userinfo的保存逻辑中添加一句int i = 1/0由此来抛出异常。再次使用postman测试:

postman测试

数据库结果:

user表
user_info表数据

可以看到的确发生了这种情况,user保存进入了数据库但对应的userinfo没有保存(因为异常而回滚)。那么现在问题出现了,我们就着手解决这个问题。

解决问题

方案一

        我们知道是因为产生的原因是因为数据库操作不在一个事务内,那我们能不能想将所有dao层操作放到一个service里面呢(如下图所示),答案是可以的,但是由于为了业务逻辑更好的分开(解耦),因此我们不建议这样做,所以这个方案否决掉。

方案一

方案二

        那我们在第一个service中先保存,再调用第二个userInfoService中的保存呢(如下图),这时候依然还是在两个事务中,我们依然缺少了之前所说的最重要的事务之间没有通讯,好在spring给我提供了解决方案,那就是事务的传播行为,试想一下在执行到第二个事务之前时候,事务自己查看是否当前已经开启事务了,如果开启了,那就让自己接下来加入第一个事务中,如果没有的话就开启一个新的事务,这样的话一旦发生异常,所有操作都在一个事务之中,因此都能够得到回滚。这也正是事务的七大传播属性之一——PROPAGATION_REQUIRED所做的工作。

方案二

七大事务的传播属性如下所示:

spring的七大事务传播属性

方案已经找到那么我们就开始改写我们的代码,我们将在controller中调用userService实现数据保存,然后在UserService中首先进行user的保存,然后调用userInfoService的save方法。并分别在service注解中加入传播属性PROPAGATION_REQUIRED。

UserService的代码

现在再来测试我们的结果,首先是正常的保存信息依然使用postman测试

测试保存

数据库结果

user表
user_info表

可以看到两条数据都正常插入了,再次给userInfo的保存中人为添加异常。


异常测试添加

查看我们的数据库,两条信息因为事务回滚都没有被保存入数据库,我们的第二种方案是可行的!

user表
userinfo_表

后言

        由此我们从一个小需求入手,简单得了解了一下数据库事务以及传播属性的相关知识,当然其中的相关知识远远不止这么一点,还有很多的知识点值的去研究与学习,同时希望我这篇文章只是抛砖引玉,希望大家多多留言与我一起探讨!

推荐阅读更多精彩内容