问题描述
嗨，
我们有两个过程: 第一个是我们的域，第二个是外部过程，我们无法控制它。
对于第一个过程来维护和改变逻辑，我们为时已晚。因此，问题是当这两个进程一起出现时-在这种情况下，我们得到死锁并等到死锁解决或一个进程放弃时。但是，当我们等待解决死锁时，我们等待了太多，所有系统 (第一个进程所在的系统) 都陷入了僵局。
我们是否可以以某种方式纠正或更改某些参数以 “缩短” 死锁解决？我们希望在180秒后解决僵局。
我们能做什么？
亲切的问候，
达科
我们有两个过程: 第一个是我们的域，第二个是外部过程，我们无法控制它。
对于第一个过程来维护和改变逻辑，我们为时已晚。因此，问题是当这两个进程一起出现时-在这种情况下，我们得到死锁并等到死锁解决或一个进程放弃时。但是，当我们等待解决死锁时，我们等待了太多，所有系统 (第一个进程所在的系统) 都陷入了僵局。
我们是否可以以某种方式纠正或更改某些参数以 “缩短” 死锁解决？我们希望在180秒后解决僵局。
我们能做什么？
亲切的问候，
达科
专家解答
通常在几秒钟内检测到同一数据库中的死锁。
跨数据库链接的死锁由distributed_lock_timeout参数控制，因为我们看不到事务的两面。
那么，您确定这是 * 死锁 * 还是只是在等待锁定？
我们需要一些细节。还可以看一下这段视频，看看你是否也受到了这种机制的影响
https://www.youtube.com/watch?v=wHcoOfA8fRM
跨数据库链接的死锁由distributed_lock_timeout参数控制，因为我们看不到事务的两面。
那么，您确定这是 * 死锁 * 还是只是在等待锁定？
我们需要一些细节。还可以看一下这段视频，看看你是否也受到了这种机制的影响
文章转载自ASKTOM，如果涉嫌侵权，请发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。
