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

问题背景

         在上周的工作中,我拿到了这样的一个需求,大致就是在一个后台节点中新增一条数据,如果新增成功则会在另外一张表中也新增一条与其相关的数据。举个例子说明的话就是在一个视频网站中,你注册了一个用户,此时后台会获取你的注册信息(用户名与密码)并将你的信息保存在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_表

后言

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

©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 157,298评论 4 360
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 66,701评论 1 290
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 107,078评论 0 237
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 43,687评论 0 202
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 52,018评论 3 286
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 40,410评论 1 211
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 31,729评论 2 310
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 30,412评论 0 194
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 34,124评论 1 239
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 30,379评论 2 242
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 31,903评论 1 257
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 28,268评论 2 251
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 32,894评论 3 233
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 26,014评论 0 8
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 26,770评论 0 192
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 35,435评论 2 269
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 35,312评论 2 260

推荐阅读更多精彩内容