社区
Java EE
帖子详情
乐观锁的问题
love19861018
2012-06-27 11:11:52
当数据库事务隔离模式是“读已提交时” 乐观锁(假设用时间戳实现)确实可以在一定程度上避免“丢失更新” 但是在高并发的场景下感觉还是可能会有点问题 例如A和B同时读取了一个表单进行修改,在多线程的情况下,会有这种情况,A通过了时间戳验证,但还没有真正提交事务,B此时如果进行时间戳校验也是可以通过验证的,也会存在B的更新把A的覆盖的现象,在一些文章中看到乐观锁假设事务会互补影响,这个假设成立吗?
欢迎拍砖!!!!
...全文
220
5
打赏
收藏
乐观锁的问题
当数据库事务隔离模式是“读已提交时” 乐观锁(假设用时间戳实现)确实可以在一定程度上避免“丢失更新” 但是在高并发的场景下感觉还是可能会有点问题 例如A和B同时读取了一个表单进行修改,在多线程的情况下,会有这种情况,A通过了时间戳验证,但还没有真正提交事务,B此时如果进行时间戳校验也是可以通过验证的,也会存在B的更新把A的覆盖的现象,在一些文章中看到乐观锁假设事务会互补影响,这个假设成立吗? 欢迎拍砖!!!!
复制链接
扫一扫
分享
转发到动态
举报
AI
作业
写回复
配置赞助广告
用AI写文章
5 条
回复
切换为时间正序
请发表友善的回复…
发表回复
打赏红包
love19861018
2012-07-04
打赏
举报
回复
[Quote=引用 3 楼 的回复:]
Select For Update 是行锁,如果能确定的只操作一行,就不会互相影响。
不过首选还是运算操作下推数据库,这种最安全可靠。
建议把场景描述下,再具体讨论。
[/Quote]
最后决定如下模式了:
1:实现一个主键锁
2:更新单据的时候采用如下逻辑:这样即兼顾了效率,又保证的业务数据的正确
if(申请主键锁){
if(校验时间戳){
更新数据
}
}
MiceRice
2012-06-28
打赏
举报
回复
Select For Update 是行锁,如果能确定的只操作一行,就不会互相影响。
不过首选还是运算操作下推数据库,这种最安全可靠。
建议把场景描述下,再具体讨论。
love19861018
2012-06-28
打赏
举报
回复
[Quote=引用楼主 的回复:]
当数据库事务隔离模式是“读已提交时” 乐观锁(假设用时间戳实现)确实可以在一定程度上避免“丢失更新” 但是在高并发的场景下感觉还是可能会有点问题 例如A和B同时读取了一个表单进行修改,在多线程的情况下,会有这种情况,A通过了时间戳验证,但还没有真正提交事务,B此时如果进行时间戳校验也是可以通过验证的,也会存在B的更新把A的覆盖的现象,在一些文章中看到乐观锁假设事务会互补影响,这个假设成立吗?
……
[/Quote]
2、Select 的时候,升级锁,常用招数是: For Update
这种模式是用数据库的悲观锁 高并发的场景会影响系统性能
现在我的实现思路大概是:读取数据的时候不会加悲观锁 因为这样会影响性能,点击保存的时候先用乐观锁 也就是时间戳通过验证之后 再用悲观锁住本单据的主键 如果获取锁成功 将数据提交到数据库进行更新 然后释放悲观锁
MiceRice
2012-06-28
打赏
举报
回复
你说的是“READ COMMITTED”吧?
这个是指A读取数据时对记录添加共享锁,
但读取结束立即释放
。另一个B对这个记录的试图修改会一直等待直到A中的读取过程结束,而不需要整个A的结束。所以,在A的不同阶段对同一记录的读取结果可能是不同的。
也就意味着可能发生:不可重复读。也就是你说的“感觉还是可能会有点问题”
这个问题说白了很简单,就是如果两个线程同时执行类似于:
Select num --> i
i = i + 1;
Update num = i;
这种过程的时候,则可能发生数据覆盖。也就是你说的“也会存在B的更新把A的覆盖的现象”
避免的方法两种:
1、计算下推数据库,也就是直接把+1的运算让数据库来负责,三步操作合并为: Update num = num + 1
2、Select 的时候,升级锁,常用招数是: For Update
不知道我这么说你能理解不。。。
常见锁策略—
乐观锁
&悲观锁
目录 1、
乐观锁
&悲观锁 1.1
乐观锁
的定义 1.2
乐观锁
的实现(CAS机制) 1.3
乐观锁
存在的
问题
:ABA
问题
1.4 悲观锁 2、公平锁&非公平锁 3、读写锁 4、独占锁&共享锁 5、可重入锁&自旋锁 1、
乐观锁
&悲观锁 1.1
乐观锁
的定义
乐观锁
认为一般情况下不会出现冲突,所以只会在更新数据的时候才对冲突进行数据检测,如果没有发生冲突则直接修改,如果发生冲突则不做任何修改,然后把结果返回给用户,让用户自行处理。 1.2
乐观锁
存在哪些
问题
?
乐观锁
存在哪些
问题
?
【锁】
乐观锁
存在的
问题
目录定义如何实现线程安全CAS执行流程CAS存在的
问题
1、循环时间太长。2、只能保证一个共享变量原子操作。3、ABA
问题
。 定义
乐观锁
总是认为你不会修改我。 如何实现线程安全
乐观锁
不加锁,通过CAS操作来实现线程安全。 Compare And Swap。 CAS执行流程 现在要修改一个数据,执行流程如下: 1、查询这个数据,得到一值。 2、准备修改这个数据,修改前判断一下值变了没。 3、真正修改这个数据。 CAS在真正修改数据时,会判断一下这个数据的值被人改了没,乐观一点,不会被别人改的,就真正的去改。
mybatis_plus
乐观锁
问题
:MP_OPTLOCK_VERSION_ORIGINAL
Mybatis_plus 出现 MP_OPTLOCK_VERSION_ORIGINAL
乐观锁
问题
org.mybatis.spring.MyBatisSystemException: nested exception is org.apache.ibatis.binding.BindingException: Parameter ‘MP_OPTLOCK_VERSION_ORIGINAL’ not found. Available parameters are [param1, et] 描述:mybatis
乐观锁
的使用场景以及失效
问题
乐观锁
是什么 以及
乐观锁
如何使用 使用场景是什么
Java EE
67,549
社区成员
225,860
社区内容
发帖
与我相关
我的任务
Java EE
J2EE只是Java企业应用。我们需要一个跨J2SE/WEB/EJB的微容器,保护我们的业务核心组件(中间件),以延续它的生命力,而不是依赖J2SE/J2EE版本。
复制链接
扫一扫
分享
社区描述
J2EE只是Java企业应用。我们需要一个跨J2SE/WEB/EJB的微容器,保护我们的业务核心组件(中间件),以延续它的生命力,而不是依赖J2SE/J2EE版本。
社区管理员
加入社区
获取链接或二维码
近7日
近30日
至今
加载中
查看更多榜单
社区公告
暂无公告
试试用AI创作助手写篇文章吧
+ 用AI写文章