SSM项目中乐观锁机制

乐观锁

乐观锁,大多是基于数据版本( Version )记录机制实现。在基于数据库表的版本解决方案中,一般是通过为数据库表增加一个 “version” 字段来实现。读取出数据时,将此版本号一同读出,之后更新时, 对此版本号加一。此时,将提交数据的版本数据与数据库表对应记录的当前版本信息进行比对,如果提交的数据版本号等于数据库表当前版本号,则予以更新,否则认为是过期数据。

优点

乐观锁机制避免了长事务中的数据库加锁开销(操作员 A和操作员 B 操作过程中,都没有对数据库数据加锁),大大提升了大并发量下的系统整体性能表现。

缺点

容易造成脏读现象

实例

用预约订单这个例子,当同时有100个人同时定一个订单但是订单只有50份就会出现超卖现象
我们使用乐观锁来处理这个问题
1.给t_ordersetting表添加version字段

alter table t_ordersetting add version1 int(11) default '0';

2.OrderSetting pojo添加version字段

private Integer version;
public Integer getVersion() {
    return version;
}

public void setVersion(Integer version) {
    this.version = version;
}

3修改预约方法

首先通过查询此订单

//根据条件查询出此订单
 OrderSetting orderSetting = orderSettingMapper.findByOrderDate(date);
//可以预约,设置预约人数加一
orderSetting.setReservations(orderSetting.getReservations()+1);
int i = orderSettingDao.editReservationsByOrderDate(orderSetting);
// 如果更新失败那么抛出异常(由于有事务所以整个方法回滚)
if(i == 0){
    throw new RuntimeException("更新失败");
}

4.Mapper接口

 //更新已预约人数(此处添加返回值,返回值是更新的行数)
 public int editReservationsByOrderDate(OrderSetting orderSetting);

5.mapper.xml

<!--更新已预约人数-->
<update id="editReservationsByOrderDate" parameterType="com.itheima.pojo.OrderSetting">
  update t_ordersetting set reservations = #{reservations},
  version = version + 1 where orderDate = #{orderDate} and version = #{version}
</update>

解释

当两个用户同时进行订单预定,第一个用户在预定时查出版本号,在更新时匹配版本号后 版本号+1,完成预定,在与此同时,另一个用户也在访问,这个用户版本号为与数据库内的不一致就更新失败,抛出异常事务回滚。

发布了13 篇原创文章 · 获赞 5 · 访问量 231

猜你喜欢

转载自blog.csdn.net/qq_38559956/article/details/103252539