天津网站设计网站制作,重庆合川企业网站建设联系电话,建大网络,长春市经济开发区人才网文章目录 介绍原因分析:修改代码一波三折#xff0c;再次出现问题 介绍
遇到了一个很有意思的问题。 在service层加了事务。 为了防止并发#xff0c;在component层加了分布式锁。
先根据前端传入的id#xff0c;在数据库中使用queryA()查到一个key然后对这个key进行加锁再… 文章目录 介绍原因分析:修改代码一波三折再次出现问题 介绍
遇到了一个很有意思的问题。 在service层加了事务。 为了防止并发在component层加了分布式锁。
先根据前端传入的id在数据库中使用queryA()查到一个key然后对这个key进行加锁再次调用queryA()。目的是为了做校验更新数据库在component层释放锁
最终现象是加锁失败。
线程A获取到了锁然后执行下面的操作。 线程B等待这把锁。 线程A执行完了之后释放锁。 线程B查数据库依然校验成功。按理说A操作了数据线程B的校验应该不通过。 实际上线程B没有读到线程A更新后的数据
原因分析:
数据库mysql的隔离级别是 可重复读。
那么在线程B等待锁的时候已经缓存了一份数据库连接了。 此时A更新了数据然后释放锁假设提交了事务由于是可重复读级别的事务隔离所以线程B此时无论如何都读不出来线程A修改的数据。 后来解决方法就是让前端传key进来。
修改代码
也就是代码改成了
1. 前端传入key
2. 然后对这个key进行加锁
3. 调用数据库的queryA()方法。目的是为了做校验
4. 更新数据库
5. 在component层释放锁此时线程A获取到了锁直到事务提交了线程B才开始数据库连接此时正常
一波三折再次出现问题
经过上面的分析 现在我也怀疑是不是在事务提交前就释放了锁呢
