Spring声明式事务和乐观锁悲观锁

文章探讨了数据库事务的隔离性,包括脏读、不可重复读和幻读问题,以及如何通过设置隔离级别如ReadCommited、RepeatableRead来解决这些问题。同时,对比了悲观锁和乐观锁的差异,悲观锁通过forupdate避免并发问题,而乐观锁利用版本控制在更新时检查冲突。Mybatisplus中实现乐观锁的方法是添加版本字段和拦截器配置。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

声明事务:

方法上添加注解@Transactional

给事务加上隔离:@Transactional(isolation=Isolation.XXX)

事务隔离性的副作用:

1. 脏读:

事务A对数据进行修改,未提交之前被事务B读取,读取后事务A对数据进行回滚,此时B读到的数据为脏数据。READ_UNCOMMITTED可能导致脏读。

2. 不可重复读

事务A读取数据以后,事务B修改了数据并提交,此后事务A再读一次数据,与先前数据不同,即不能重复读同一数据。READ_COMMITED可以解决脏读,但是不能解决不可重复读。

3. 幻读

事务A对数据修改了以后还未提交之前,事务B也对此数据进行修改,事务A对此数据进行读取发现和之前修改的数据不同,好像产生幻觉。REPEATABLE_READ可以解决脏读、不可重复读,但是不能解决幻读。

 乐观锁与悲观锁

大多数应用程序把数据库的隔离级别设置为Read committed(Mysql 的默认隔离级别为Repeatable read)。read commited可以解决脏读,但是不能解决不可重复读和幻读,但是拥有较好的并发性能。

在可能出现不可重复读和幻读的场合,使用乐观锁和悲观锁来控制。

悲观锁:

悲观锁假定共享资源被其他人访问时就会出现问题,因此在自己访问时给资源上锁拒绝其他线程使用查询意外的操作。

在sql语句中可以使用select……for update来实现悲观锁。

乐观锁:

悲观锁会阻塞线程,在高并发场景下并不适用。因此在一般情况下使用乐观锁。

乐观锁假设认为数据一般情况下不会造成冲突,仅在数据进行提交更新的时候,才会正式对数据的冲突与否进行检测。

乐观锁大多是基于数据版本( Version )记录机制实现。即为数据增加一个版本标识。读取出数据时,将此版本号一同读出,之后更新时,将提交数据的版本数据与数据库表对应记录的当前版本信息进行比对,如果提交的数据版本号等于数据库表当前版本号,则予以更新并对此版本号加一,否则认为是过期数据。

Mybatis plus实现乐观锁:

1. 通过配置类配置拦截器

2. 在实体类增加verision字段,加上version注解,数据库表项增加version列

评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值