| 设为首页 加入收藏 |
当前位置: |
| TOP | ||||||||||||||||||||||||||||||
|
并发下的事务处理(一)
注意:我们讨论隔离级别的场景,主要是在多个事务并发的情况下,因此,接下来的讲解都围绕事务并发。 未提交读 公司发工资了,领导把5000元打到singo的账号上,但是该事务并未提交,而singo正好去查看账户,发现工资已经到账,是5000元整,非常高兴。可是不幸的是,领导发现发给singo的工资金额不对,是2000元,于是迅速回滚了事务,修改金额后,将事务提交,最后singo实际的工资只有2000元,singo空欢喜一场。
出现上述情况,即我们所说的脏读,两个并发的事务,“事务A:领导给singo发工资”、“事务B:singo查询工资账户”,事务B读取了事务A尚未提交的数据。 当隔离级别设置为Readuncommitted时,就可能出现脏读,如何避免脏读,请看下一个隔离级别。 读提交 singo拿着工资卡去消费,系统读取到卡里确实有2000元,而此时她的老婆也正好在网上转账,把singo工资卡的2000元转到另一账户,并在singo之前提交了事务,当singo扣款时,系统检查到singo的工资卡已经没有钱,扣款失败,singo十分纳闷,明明卡里有钱,为何...... 出现上述情况,即我们所说的不可重复读,两个并发的事务,“事务A:singo消费”、“事务B:singo的老婆网上转账”,事务A事先读取了数据,事务B紧接了更新了数据,并提交了事务,而事务A再次读取该数据时,数据已经发生了改变。 当隔离级别设置为Readcommitted时,避免了脏读,但是可能会造成不可重复读。 大多数数据库的默认级别就是Readcommitted,比如Sql Server , Oracle。如何解决不可重复读这一问题,请看下一个隔离级别。 重复读 当隔离级别设置为Repeatableread时,可以避免不可重复读。当singo拿着工资卡去消费时,一旦系统开始读取工资卡信息(即事务开始),singo的老婆就不可能对该记录进行修改,也就是singo的老婆不能在此时转账。 虽然Repeatableread避免了不可重复读,但还有可能出现幻读。 singo的老婆工作在银行部门,她时常通过银行内部系统查看singo的信用卡消费记录。有一天,她正在查询到singo当月信用卡的总消费金额(select sum(amount) from transaction where month =本月)为80元,而singo此时正好在外面胡吃海塞后在收银台买单,消费1000元,即新增了一条1000元的消费记录(insert transaction... ),并提交了事务,随后singo的老婆将singo当月信用卡消费的明细打印到A4纸上,却发现消费总额为1080元,singo的老婆很诧异,以为出现了幻觉,幻读就这样产生了。 注:Mysql的默认隔离级别就是Repeatableread。 序列化 Serializable是最高的事务隔离级别,同时代价也花费最高,性能很低,一般很少使用,在该级别下,事务顺序执行,不仅可以避免脏读、不可重复读,还避免了幻像读。 PS:大多数数据库都是使用提交读,作为默认的隔离级别,如Oracle、SqlServer。因为在数据量访问的情况下,这种方式性能较好,同时防止了脏读的情况发生,尽管有不可重复读的情况,但是在可承受的范围内;也有一些数据采用重复读,作为默认的隔离级别。如果采用默认配置,那么使用MySql的性能会稍低一些。MySql隔离级别的默认配置实现,原理是数据访问时加了读写锁,并发读取时,分别加锁,但是只有第一个加锁的事务,才能修改事务,其他事务不能修改,它避免了可重复读的情况。序列化同样是加锁,但是它加的是独占锁,无论哪个线程读取到数据,立马会将其霸占,直至其操作完成。这种方式一致性高,但是并发性不好,很少使用。 事务的传播特性在开发中,我们一个action中,可能调用多个Service,那么这种情况,是如何保证事务的呢?事务的传播特性。下面我们来看看Spring事务的传播特性:
|
||||||||||||||||||||||||||||||
| 评论 |
|
|
| ·python数据分析岗的 | (2025-12-25 10:02:21) |
| ·python做数据分析需 | (2025-12-25 10:02:19) |
| ·成为一个优秀的pytho | (2025-12-25 10:02:16) |
| ·Java后端面试实习自 | (2025-12-25 09:24:21) |
| ·Java LTS版本有哪些 | (2025-12-25 09:24:18) |