MyBatis-Plus通过version机制实现乐观锁的思路

MyBatis-Plus是通过version机制实现乐观锁的。

大致思路:

  • 取出记录,携带记录的当前version
  • 更新记录的时候,比较记录当前的version是否有改变;
  • 如果version未改变,则更新记录,并更新version,一般值+1
  • 如果version改变了,则不更新记录。

version机制的核心思想就是,假设发生并发冲突的几率很低,只有当更新数据的时候采取检查是否有冲突,而判断是否有冲突的依据就是version的值是否被改变了。

配置

MyBatis-Plus中配置乐观锁分两步:

  • 实例化OptimisticLockerInnerInterceptor,并添加到MyBatis-Plus的拦截器链中;
  • 定义version字段,并在Entity中使用@Version注解注释version字段。

说明:

支持的数据类型只有: intIntegerlongLongDateTimestampLocalDateTime

整数类型下 newVersion = oldVersion + 1

newVersion 会回写到 entity 中;

仅支持 updateById(id)update(entity, wrapper) 方法;

update(entity, wrapper) 方法下, wrapper 不能复用!!!

配置如下:

首先,实例化OptimisticLockerInnerInterceptor,并添加到拦截器链中:

@Configuration
public class MyBatisPlusConfig {

    /**
     * 插件配置
     *
     * @return
     */
    @Bean
    public MybatisPlusInterceptor mybatisPlusInterceptor() {
        MybatisPlusInterceptor interceptor = new MybatisPlusInterceptor();
        // 向MyBatis-Plus的过滤器链中添加分页拦截器,需要设置数据库类型(主要用于分页方言)
        interceptor.addInnerInterceptor(new PaginationInnerInterceptor(DbType.MYSQL));
        // 添加乐观锁拦截器
        interceptor.addInnerInterceptor(new OptimisticLockerInnerInterceptor());
        return interceptor;
    }
}

然后,使用@Version注解:

@Data
@TableName("tb_user")
public class UserEntity {
    private Long id;
    private String name;
    private Integer age;
    private String email;

    @TableField(value = "create_time", fill = FieldFill.INSERT)
    private Date createTime;

    @TableField(value = "update_time", fill = FieldFill.INSERT_UPDATE)
    private Date updateTime;

    @TableLogic(value = "0", delval = "-1")
    @TableField(value = "delete_flag", fill = FieldFill.INSERT)
    private Integer deleteFlag;

    @Version
    @TableField(value = "version", fill = FieldFill.INSERT)
    private Integer version;
}

配置insert时候,version默认值赋1

/**
 * 自动填充字段值得配置
 */
@Component
public class AutoFillFieldValueConfig implements MetaObjectHandler {

    @Override
    public void insertFill(MetaObject metaObject) {
        this.strictInsertFill(metaObject, "createTime", Date.class, new Date());
        this.strictInsertFill(metaObject, "updateTime", Date.class, new Date());
        this.strictInsertFill(metaObject, "deleteFlag", Integer.class, 0);
        this.strictInsertFill(metaObject, "version", Integer.class, 1);
    }

    @Override
    public void updateFill(MetaObject metaObject) {
        this.strictUpdateFill(metaObject, "updateTime", Date.class, new Date());
    }
}

测试一下

1.测试新增记录

首先新增一条数据:

@Test
    public void testVersionInsert() {
        // 插入一个新的用户
        UserEntity newUser = new UserEntity();
        newUser.setId(12L);
        newUser.setName("Kelly");
        newUser.setAge(28);
        newUser.setEmail("Kelly@163.com");
        userMapper.insert(newUser);
    }

控制台日志:

==>  Preparing: INSERT INTO tb_user ( id, name, age, email, create_time, update_time, delete_flag, version ) VALUES ( ?, ?, ?, ?, ?, ?, ?, ? )
==> Parameters: 12(Long), Kelly(String), 28(Integer), Kelly@163.com(String), 2021-09-25 00:14:23.894(Timestamp), 2021-09-25 00:14:23.896(Timestamp), 0(Integer), 1(Integer)
<==    Updates: 1

数据库数据:

可以看到,新增记录时,version默认赋值为1

2.测试更新记录

下面,来测试一下更新记录,看看version的变化。

   @Test
    public void testVersionUpdate() {
        // 查询用户记录
        UserEntity updateUser = userMapper.selectById(12L);
        // 更新用户记录
        updateUser.setId(12L);
        updateUser.setAge(30);
        userMapper.updateById(updateUser);
    }

注意:这里有一个坑!

一定要先查询出这条数据,再更新,乐观锁才会生效!!!

控制台打印的日志:

==>  Preparing: SELECT id,name,age,email,create_time,update_time,delete_flag,version FROM tb_user WHERE id=? AND delete_flag=0
==> Parameters: 12(Long)
<==    Columns: id, name, age, email, create_time, update_time, delete_flag, version
<==        Row: 12, Kelly, 30, Kelly@163.com, 2021-09-25 00:14:24, 2021-09-25 00:20:24, 0, 1
<==      Total: 1

......

==>  Preparing: UPDATE tb_user SET name=?, age=?, email=?, create_time=?, update_time=?, version=? WHERE id=? AND version=? AND delete_flag=0
==> Parameters: Kelly(String), 30(Integer), Kelly@163.com(String), 2021-09-25 00:14:24.0(Timestamp), 2021-09-25 00:20:24.0(Timestamp), 2(Integer), 12(Long), 1(Integer)
<==    Updates: 1

数据库数据:

可以看到,version字段由原来的1,更新为2

到此这篇关于MyBatis-Plus通过version机制实现乐观锁的思路的文章就介绍到这了,更多相关MyBatis Plus实现乐观锁内容请搜索我们以前的文章或继续浏览下面的相关文章希望大家以后多多支持我们!

(0)

相关推荐

  • mybatis-plus乐观锁实现方式详解

    悲观锁.乐观锁简介: 悲观锁:同步操作.即用户A在操作某条数据时,为其上锁,限制其他用户操作,用户A操作完成提交事务后其他用户方可操作此数据. 乐观锁:使用版本控制字段.更新某条数据时,先判断此数据的version是否符合条件,若符合则更新反之更新失败. mybatis-plus乐观锁实现方式 1.向数据库中添加版本控制字段version ALTER TABLE `user` ADD COLUMN `version` INT 2.实体类中对应此字段添加@Version注解 特别说明: 特别说明:

  • Mybatis plus的自动填充与乐观锁的实例详解(springboot)

    自动填充 项目中经常会遇到一些数据,每次都使用相同的方式填充,如插入时间.更新时间.Mybatis-plus的自动填充功能可以帮助我们快速实现. 1.表中加入create_time,update_time字段 2.实体类注解填充字段 @TableField(fill= FieldFill.INSERT) private Date createTime; @TableField(fill = FieldFill.INSERT_UPDATE) private Date updateTime; /**

  • MP(MyBatis-Plus)实现乐观锁更新功能的示例代码

    实现步骤 step1:添加乐观锁拦截器 MP的其他拦截器功能可以参考官网 @Bean public MybatisPlusInterceptor mybatisPlusInterceptor() { MybatisPlusInterceptor interceptor = new MybatisPlusInterceptor(); interceptor.addInnerInterceptor(new OptimisticLockerInnerInterceptor()); return int

  • MyBatis-Plus通过version机制实现乐观锁的思路

    MyBatis-Plus是通过version机制实现乐观锁的. 大致思路: 取出记录,携带记录的当前version: 更新记录的时候,比较记录当前的version是否有改变: 如果version未改变,则更新记录,并更新version,一般值+1: 如果version改变了,则不更新记录. version机制的核心思想就是,假设发生并发冲突的几率很低,只有当更新数据的时候采取检查是否有冲突,而判断是否有冲突的依据就是version的值是否被改变了. 配置 MyBatis-Plus中配置乐观锁分两

  • redis中事务机制及乐观锁的实现

    Redis事务机制 在MySQL等其他数据库中,事务表示的是一组动作,这组动作要么全部执行,要么全部不执行. Redis目前对事物的支持相对简单.Redis只能保证一个client发起的事务中的命令可以连续的执行,而中间不会插入其他的client命令.当一个client在一个链接中发出multi命令时,这个链接会进入一个事务上下文,该连接后续的命令不会立即执行,而是先放到一个队列中,当执行exec命令时,redis会顺序的执行队列中的所有命令. Multi 开启事务: 127.0.0.1:637

  • Spring Boot2+JPA之悲观锁和乐观锁实战教程

    目录 前言 悲观锁与并发 利用SQL的for update解决并发问题 利用JPA的@Lock行锁注解解决并发问题 如果是@NameQuery,则可以 乐观锁与并发 利用version字段解决并发问题 利用JPA的@Version版本机制解决并发问题 什么时候用悲观锁或者乐观锁 前言 大量的请求,或者同时的操作,容易导致系统在业务上发生并发的问题. 通常讲到并发,解决方案无非就是前端限制重复提交,后台进行悲观锁或者乐观锁限制. 悲观锁与并发 悲观锁(Pessimistic Lock),顾名思义,

  • MySQL悲观锁与乐观锁的实现方案

    目录 前言 实战 1.无锁 2.悲观锁 3.乐观锁 总结 前言 悲观锁和乐观锁是用来解决并发问题的两种思想,在不同的平台有着各自的实现.例如在Java中,synchronized就可以认为是悲观锁的实现(不严谨,有锁升级的过程,升级到重量级锁才算),Atomic***原子类可以认为是乐观锁的实现. 悲观锁 具有强烈的独占和排他特性,在整个处理过程中将数据处于锁定状态,一般是通过系统的互斥量来实现.当其他线程想要获取锁时会被阻塞,直到持有锁的线程释放锁. 乐观锁 对数据的修改和访问持乐观态度,假设

  • 深入理解Yii2.0乐观锁与悲观锁的原理与使用

    本文介绍了深入理解Yii2.0乐观锁与悲观锁的原理与使用,分享给大家,具体如下: Web应用往往面临多用户环境,这种情况下的并发写入控制, 几乎成为每个开发人员都必须掌握的一项技能. 在并发环境下,有可能会出现脏读(Dirty Read).不可重复读(Unrepeatable Read). 幻读(Phantom Read).更新丢失(Lost update)等情况.具体的表现可以自行搜索. 为了应对这些问题,主流数据库都提供了锁机制,并引入了事务隔离级别的概念. 这里我们都不作解释了,拿这些关键

  • Java并发问题之乐观锁与悲观锁

    首先介绍一些乐观锁与悲观锁: 悲观锁:总是假设最坏的情况,每次去拿数据的时候都认为别人会修改,所以每次在拿数据的时候都会上锁,这样别人想拿这个数据就会阻塞直到它拿到锁.传统的关系型数据库里边就用到了很多这种锁机制,比如行锁,表锁等,读锁,写锁等,都是在做操作之前先上锁.再比如Java里面的同步原语synchronized关键字的实现也是悲观锁. 乐观锁:顾名思义,就是很乐观,每次去拿数据的时候都认为别人不会修改,所以不会上锁,但是在更新的时候会判断一下在此期间别人有没有去更新这个数据,可以使用版

  • 浅谈mybatis 乐观锁实现,解决并发问题

    情景展示: 银行两操作员同时操作同一账户就是典型的例子. 比如A.B操作员同时读取一余额为1000元的账户,A操作员为该账户增加100元,B操作员同时为该账户扣除50元,A先提交,B后提交.最后实际账户余额为1000-50=950元,但本该为1000+100-50=1050.这就是典型的并发问题. 乐观锁机制在一定程度上解决了这个问题.乐观锁,大多是基于数据版本(Version)记录机制实现.何谓数据版本?即为数据增加一个版本标识,在基于数据库表的版本解决方案中,一般是通过为数据库表增加一个 "

  • 浅谈Mybatis乐观锁插件

    背景:对于数据库的同一条记录,假如有两个人同时对数据进行了修改,然后最终同步到数据库的时候,因为存在着并发,产生的结果是不可预料的.最简单的解决方式就是通过给表的记录加一个version字段,记录在修改的时候需要比较一下version是否匹配,如果匹配就更新,不匹配就直接失败.更新成功则把version+1,也就是所谓的乐观锁.当然这样的逻辑最好能做到对开发人员透明,本插件就是来做这件事情的. 1. 使用方式:在mybatis配置文件中加入如下配置,就完成了. <plugins> <pl

随机推荐