网上很容易搜到的这种乐观锁实现方案真的正确吗?

发布于 2022-09-04 14:28:57 字数 921 浏览 27 评论 0

网上找到的方案是这个样子的:

1.开始一个事务
begin;
2.查询出商品信息
select status, version from t_goods where id=#{id}
假定 status 查询出来为1,表示未卖出,2代表已经卖出
3.根据商品信息(t_goods)生成订单
insert into t_orders values (null, #id);
4.修改商品status为2
update t_goods
set status=2
where id=#{id} and version=#version
如果更新条数为0就回滚事务,如果更新条数为1就提交事务

维基百科上的关于乐观并发控制的定义:Optimistic concurrency control
其中提到

When conflicts are rare, transactions can complete without the expense of managing locks and without having transactions wait for other transactions' locks to clear, leading to higher throughput than other concurrency control methods

这个意思应该是说完成一个事务是没有加锁的需要,也不需要等待别的事务的锁。

但是如果按照上面展示的实现方案,最后一步如果是在MySQL上执行,我测试过如果是可重复读的事务隔离级别,如果一个事务对一行数据进行了update,在没有提交之前,其他事务如果想对同一行数据进行update,是需要等待前一个事务提交才行的,也就是写锁(网上有人称为X锁)。如果是这样,那么岂不是和维基百科上的定义出分歧了。这个实现方案正确吗?求解

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。
列表为空,暂无数据
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文