分布式锁与正常spring事务之间先后问题

似故人来 发布于 2018/07/10 13:43
阅读 2K+
收藏 0

有这么一个问题,就是并发情况下当锁优先于事务提交之前就被释放了,那么这时就很可能出问题。不知道有没有大佬有什么idea,感谢。

加载中
0
学而不思则罔
学而不思则罔

不知道你用的什么锁方案?我们项目使用redis的SETNX实现分布式锁。在controller层按互斥条件锁定,利用事务控制在service层这点,最后等业务层代码处理完,再解锁不存在你说的问题。

学而不思则罔
学而不思则罔
回复 @似故人来 : 如果是控制业务层的某个细粒度操作,有个笨拙的方法,秉承锁在哪创建,在哪解锁的原则。还是在controller层获取锁,把锁对象作为参数传入业务层使用,解锁还是在biz结束后controller层解锁接口。这样在何种粒度都可以控制。
似故人来
似故人来
你们的方案想了下确实可行,但是某种程度上来说,粒度大了些。
似故人来
似故人来
目前也是在用setnx方案,原因是项目为阿里私有云,redis版本不支持lua脚本,没法使用redission提供的锁方案。所以也是用setnx。
0
济南大飞哥
济南大飞哥

有解决方案了吗?

0
983674707
983674707

可以考虑分布式锁加乐观锁的方案。乐观锁修改失失败时,可以重试,设置最大的重试次数;分布式锁保证减少可能发生重试的机率。这种方案效率低一些,但是不需要考虑事务。

0
炎黄伙哥
炎黄伙哥

这不是一个冷门的问题,比如使用redis实现,可以用一个线程给这些锁延长过期时间。现成的实现可以了解redisson的lock实现

OSCHINA
登录后可查看更多优质内容
返回顶部
顶部
返回顶部
顶部