seata 1.7 TCC 开启useFence会造成数据库死锁问题如何解决?

rfbsl7qr  于 3个月前  发布在  其他
关注(0)|答案(7)|浏览(46)

在防止悬挂的时候在select * from tcc_fence_log for update没有查询到的时候,需要插入一条事务记录,使用MySQL 8数据的时候会出现死锁,除开加分布式锁,是否有其他解决办法?

x7rlezfr

x7rlezfr1#

Why is there a deadlock, do you have more log information?

cl25kdpy

cl25kdpy2#


在并发的情况下,事务1 、事务2 在 代码上图代码A点执行 select ... from tcc_fence_log for update语句时, 如果查询事务记录不存在会添加间隙锁,如果两个事务添加的间隙锁范围包含两个事务之后insert事务记录的记录范围(上图代码B) 事务1会添加插入意向锁进入等待,等待事务2提交事务释放间隙锁 事务2会添加插入意向锁进入等待,等待事务1提交事务释放间隙锁 这就会形成数据库死锁; 日志信息:

vngu2lb8

vngu2lb83#

MySQL 8默认事务隔离级别 可重复读

xqkwcwgp

xqkwcwgp4#

Looking at the logs it does have that issue, but your description I think is wrong because he is operating in a local transaction using the same connection, and you didn't describe clearly the point in time of the query and insert for transaction 1 and the query and insert for transaction 2, and according to your description transaction 1 has got the gap lock and the intent lock, so why is it waiting for transaction 2?

看日志确实有该问题,但是你的描述我认为是错误的,因为他在一个本地事务中,使用的是相同的connection进行的操作,你也没有描述清楚事务1的查询和插入,以及事务2的查询和插入的时间点,按照你的描述,事务1已经拿到间隙锁和意向锁,为什么要等待事务2?

f4t66c6m

f4t66c6m5#

You can change to rc isolation level, which should solve the problem directly

ha5z0ras

ha5z0ras6#

我觉得我还是需要把它描叙清楚:(我个人觉得在MySQL默认隔离级别下出现的概率还是比较高的)

izj3ouym

izj3ouym7#

我觉得我还是需要把它描叙清楚:(我个人觉得在MySQL默认隔离级别下出现的概率还是比较高的)

Check the MySQL version.In higher versions of the database, there is no GAP lock for equivalence operations.

相关问题