Sql server 在应用程序中使用数据库死锁作为工作流

我最近发现我们的ERP软件在MS SQL数据库中造成了很多死锁。 对我来说，我们应该永远避免僵局。如果我们有一个，我们应该追踪它以了解原因，并做出改变以消除它们

但该软件供应商表示，设计上是这样的：

1-将新记录插入表a中，以便进行处理

2-我们有2台JBoss服务器，监控同一个表中的新记录。 一旦有一台服务器可用，它将处理记录并 然后删除/修改已处理的记录

3-当然，如果2 如果服务器可用，将导致死锁

4-最后，对于应用程序来说，这不是一个问题，因为JBoss 服务器将成功完成该过程。基于此,， 软件供应商说死锁不是问题

这每天造成大约50到100个僵局。 让所有这些解除锁定都发生是好的吗？（原因已查明） 如果不是的话，我希望你们有充分的理由要求他们修改他们的软件流程

---

谢谢

如果轮询的逻辑是这样的，那么我有种子死锁：

select top 1 @ID = ID from QUEUE where STATUS = 0

update QUEUE set STATUS = 1 where ID = @ID

这会导致死锁，因为有时两个作业在另一个作业能够更新ID之前获取相同的ID

---

使用查询提示或在一条语句中执行update+select可以很容易地解决这个问题。如果您不知道什么类型的查询实际导致了死锁，那么这可能没有帮助。

这是实际的死锁吗？还是仅仅是一个事务阻塞了另一个事务？我可以看到被锁定的行阻塞了另一个事务，但实际的死锁是没有意义的。据我所知，基于我的sql监控工具，它们是死锁。见下面詹姆士的答案，和我的模式一样。这正是我对这个问题的理解。但是，要求软件供应商修改以使用查询提示避免死锁有多重要？它会更有效吗？等等。当它确定要终止哪个进程时，它可能会停止处理一小段时间。很可能对整个进程影响不大，但如果人们停止监视，它当然可能会隐藏其他死锁：）