1
RainCats 179 天前 1
浅薄看了点书,for update 用的是当前读,会刷新当前事务中读取到的数据版本。
要不试试搞个分布式锁去确保同一时间只有一个可以操作到。 |
2
pkoukk 179 天前
从你的业务描述上看,我没看到锁主表的必要性...
既然两个都是成功,目标都是改为审核通过,那为什么要锁呢 |
3
skaly 179 天前 1
尽量不要用存储过程/触发器什么的,出现问题调试起来非常麻烦
鉴于你这个问题,可以考虑在主表里面 加两字段 count ,u_count 。 每次更新 u_count 的时候,使用 u_count=u_count+1 然后再判断 u_count 是否=count ,来决定是否 审核通过 |
4
1018ji 179 天前 1
-- 查询字表明细记录(这部如果去除整个流程正常)-
SELECT * FROM a_detail WHERE id = 1 这个东西会影响后面的查询吧,我估计表现就是这样的 -- 查看子表是不是都已经审核通过了-- select count(0) from a_detail WHERE auid = 'a1' and approval_status!=2; --------------------------------------------------------------------------------------- 还是考虑 3 的做法,但是有个问题是如果代码不够牛逼,很容易错乱也就是说导致 u_count 少了。 你这个事务太大了,这个事务就是个灾难 |
5
1018ji 179 天前
https://www.jianshu.com/p/eb3f56565b42 补充个文章,自己测试对不对吧
|
6
MoYi123 179 天前
难道不是每次子审核通过就 直接跑这 2 句就行? 都不用在一个事务里.
UPDATE a_detail set approval_status = 2 WHERE id = 2 and approval_status = 1; UPDATE a set approval_status=(select count(0)==0 from a_detail WHERE auid = 'a1' and approval_status!=2) where uid='a1' |
9
rqxiao OP @pkoukk 最后两个审核通过的他们在事务里都没有提交的时候,不是 count 自己事务内 当前内已提交事务的数量吗,有可能都 2 个线程都是 count 出 9 个 如果总共审核通过的是 10 个的话
|
10
Dream95 179 天前 1
事件驱动,子表审核通过触发审核事件,处理审核事件时再去检查全部任务是否通过审核
|
11
bsg1992 179 天前
这个不算问题吧, 审批触发事件后,查询一下审批记录,满足数量更新主表的状态值就好了啊
|
12
LiaoMatt 179 天前
我觉得通过 MQ 来实现会更好, 或者你把事务隔离级别设置为读已提交是不是就可以了
|
14
wengyanbin 179 天前
@rqxiao 难道是在事务开始时候的 select * from a_detail where id =这一句影响了后面的 count ?就算去掉开始的语句我也觉得会有幻读的问题的,两个事务里面的 count 应该都是快照读才对。
|
15
rqxiao OP @wengyanbin 并发时,每个会话开启事务,获取到行锁之后,进行一次快照读。只要能获取到行锁,说明上个事务已经提交了。所以并发情况下,达到了串行执行业务。获取到行锁一定能查询当前准确的数据。为什么说会有幻读?
目前来看 select * from a_detail where id =这一句是影响了后面的 count 。就算我替换成 select * from student a 。与本业务完全不相关的表查询,也会有问题。不是很理解为什么 碍于本人现在的认知水平,理解有可能也不是对的。 |
17
long952 179 天前
把第一个查询语句放在 for update 后面试试,rr 级别第一次查询生成一个 ReadView ,解决幻读问题,以后每次读取还是这个 readview ,数据还是旧的
|
19
rqxiao OP @long952 我以前看网上资料的,rr 级别第一次查询生成一个 ReadView 。都是用 select 一条记录作为演示。
我一直以为是 readview 是跟记录绑定的。不同的记录会绑定不同的 readvie ,现在这个现象感觉和不是记录级别,感觉是整个表级别。 |
20
wengyanbin 178 天前
@rqxiao 问题应该还是在 count 的地方,产生了一个快照读。但我个人分析还是觉得无论前面那一句查询加不加都会是快照读,也就是无论怎样都会有幻读的问题才对。不加 select * from a_detail where id =这一句事务反而能够正常跑是我不能理解。现在不知道从哪里分析问题了
|
21
rqxiao OP @wengyanbin 你指的幻读问题具体是指什么问题
|
22
wengyanbin 178 天前
@rqxiao 在这里事务一更新了 detail 然后去 count ,这个时候 count(0)=1 ,所以事务一没有更新表 a ;事务二跟事务一是并发的,count(0)也是等于 1 ,也没有更新表 a 。原因就是因为 count(0)这个地方是 ReadView ,两个事务读出来 count(0)都不等于 0.
|
23
rqxiao OP @wengyanbin rr 级别在 在事务开启后第一次发生快照读的时候生成 readview 而非 事务开启时生成 readview 。所以后获取到行锁的事务在 update 自己的记录后,count ( 0 )就是等于 0 。
如果按照你的说法,在 rr 级别,那第二个事务也永远不会 count=0 了? 因为根据 mvcc ,他确实会读取到事务一提交完的数据,你可以自己测试下。count 的结果和事务开始的时间无关,和第一次进行快照读有关 而且幻读的定义不是事务中,同时进行两次 查询发现 count 数量不一致,这个场景一个事务里没有 count 多次啊? 如果理解有误请指出 |
25
rqxiao OP @wengyanbin 而且只要能获取到行锁,说明上个事务已经提交了
|
26
wengyanbin 178 天前
@rqxiao 没注意到行锁是同一个对象,能获取到行锁确实证明上个已经提交。我说的幻读的那种场景是例如会议室预定,两个人同时预定同个时间段的会议室,通过 select count()来判断是否有预定,在 rr 级别下,会出现两个事务并发进行,都先判断无人预定,然后就会产生写冲突。
|
27
wenxueywx 178 天前
rr 等级的 readview 是事务开始时创建,事务在整个生命周期内使用相同的 readview 。我理解题主的意思是 A 、B 两个事务并行,A 事务已经提交的数据,B 事务是通过 readview 是读不到的。查询子表状态时采用当前读可以解决:select count(0) from a_detail WHERE auid = 'a1' and approval_status!=2 lock in share mode ;
其次,主表没有加锁的必要 |
28
keepme 178 天前
1. 那是因为读视图是在 SELECT * FROM a_detail WHERE id = 2 和 SELECT * FROM a_detail WHERE id = 1 的时候创建的,后续的更新操作不会更新读视图,所以查不到对方事务数据的更改
2. 如果没有上面两个 sql 语句,读视图会在 SELECT * FROM `a` where uid='a1' for update;这条 sql 的时候创建读视图,这样只有一个事务执行完毕,另一个事务才会创建读视图,所以不存在 count 不到的问题。 |
31
rqxiao OP @wenxueywx A 、B 两个事务并行,A 事务已经提交的数据,B 事务是通过 readview 是读不到的。
这句话也是错的 ,rr 级别根据 mvcc 生成 readview ,那按照你说的话,在 rr 级别只要 b 事务和 a 事务同时开启,b 事务就永远不可能读到 a 事务已提交的数据吗,但实际不是的 |
32
rqxiao OP @wenxueywx 原先就是设想 在 rr 级别为了 让 count 操作串行执而利用行锁,并且让 count 操作在获取行锁立马执行,确保能读到已经提交的数据。所以说本来的意思想 A 事务已经提交的数据,B 事务是通过 readview 能读到
|
33
wenxueywx 177 天前
@rqxiao 1 、“rr 等级的 readview 是事务开始时创建”确实不对,准确地说,rr 等级的 readview 创建时机是事务中首次执行 sql 时,此事务中的快照读都是基于该 readview 。
2 、A 、B 两个并行的事务,A 可以通过当前读获取 B 事务已经提交的数据,不能通过快照读读到。 3 、 加锁和 count 读是两个操作,count 依然是读的快照,不会因为你加锁而读最新数据,你需要 count 进行当前读 |
34
rqxiao OP @wenxueywx 你的意思是在每个事务里 ,先 update 各自 id 的状态,后执行 select count(*) from a_detail where approval_status!=3 and auid='a1' lock in share mode;
吗 ,实测下来 select count(*) lock in share mode;会阻塞,死锁。 是我理解执行有问题吗 |
35
rqxiao OP @wenxueywx
根据本人目前掌握理解的水平, 如果主表不加锁, a 事务和 b 事务 都分别各自按照下面 sql 执行执行 ====sessionA begin; UPDATE a_detail set approval_status = 2 WHERE id = 1 and approval_status = 1; select count(0) from a_detail WHERE auid = 'a1' and approval_status!=2 lock in share mode ; commit; =====sessionB begin; UPDATE a_detail set approval_status = 2 WHERE id = 2 and approval_status = 1; select count(0) from a_detail WHERE auid = 'a1' and approval_status!=2 lock in share mode ; commit; 各自执行 update where id=都会加上各自 id 的行锁, 但各自执行到 select count()都要去根据 auid 这个非唯一索引进行等值查询,都会触发各自的间隙锁,但是又与对方事务的行锁冲突,造成死锁 |
38
wenxueywx 165 天前
6 楼说的对,子表更新与统计子表更新成功的条数后更新主表 没必要在一个事务
|
39
wengyanbin 119 天前 via Android
重新看过问题,我有一个想法。题主你原来没问题的写法,两个事务同时开启,在第一句 SQL 的时候发生了锁竞争,有一个事务阻塞没有产生快照,直到另一个事务完成才获得锁并产生快照。这时候的快照已经是最新的,所以最后按照你的设计执行成功。在 for update 加上的那一句查询,使得两个事务都同时获得各自的快照,后面的操作其实都是在快照上面执行的。
|