spring synchronized锁和事务

本文探讨了在并发环境下,事务与锁的交互作用及潜在风险。特别关注了Propagation.REQUIRES_NEW特性,揭示了不当使用可能导致的数据一致性问题,并提出了锁与事务的合理组合建议。

最近发现有同事写了一段事务控制的方法中子方法加了锁的代码,而且在事务上用了propagation = Propagation.REQUIRES_NEW,然后稍微研究了下,得出以下结论:

1. propagation = Propagation.REQUIRES_NEW在执行方法时,不管之前有没有事务,都会创建新的事务,而且这个一般用于嵌套事务的内层事务中,像xxx那样写也有效,不过一般不那样用。
2. 目前用的是事务(_NEW)在外层,锁在内层的写法,这种写法有风险。并发情况下,A在执行有锁的部分并且有自己的事务,B进来时会创建自己的事务(因为用了_NEW)并且等A执行完有锁的部分。等A执行完有锁的部分,A事务开始执行save,B开始执行有锁的部分,如果A save还没提交,B还是会拿到旧的。 间隔时间很短的情况会取到旧数据,人工很难重现。
3. 如果继续用这种写法,但不用_NEW,用默认事务,会这样子:在执行有锁的部分并且有自己的事务,B进来时会用A的事务并且等A执行完有锁的部分。等A执行完有锁的部分,A事务开始执行save,B开始执行有锁的部分,如果B save还没提交,A save也不会提交,这样B拿到的肯定是旧的。而且这样很乱,肯定是错的。
4. 建议写法是锁在外层,事务在内层,这样事务就会被锁管理,事务执行完后锁才会被释放,原理是锁管理事务。

5. 在service层如果用一个加锁的外层函数调用有事务控制的方法,sonarQube(一个代码风格检查工具)提示可能会有问题,后面在controller那边加了锁,不过之后还是要看下在service层到底有什么问题。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值