DeadLock DbContext并发事务

Question

​

​

嗨，请看上图中的死锁图部分。我有两个更新同一个表的事务，其中一个是长事务，更新该表(同一行)5次，但另一个事务只更新该表一次，是两个DB命中的小事务，从死锁图中.Its逻辑为真，这两个事务在不同的行上都有X锁，并试图获得U锁。我不明白为什么较短的事务获取X锁，尽管它还没有触发update查询(因为它是导致死锁的更新查询，这意味着它还没有被触发)。任何帮助都是非常容易接受的。1)我使用的是隔离级别read committed。2)我不能理解为什么第二个/第一个事务可以获得X锁，而另一个事务已经在某些行上获得了它。我在更新查询时读到，当一个事务具有X锁时，第一个U锁被应用，然后被升级为X锁，当一个事务具有X锁时，另一个事务如何具有U锁，因为在表扫描期间(以确定要更新的行)，它不能通过其他事务读取具有X锁的行。3)两个事务都更新同一table.Any的一个不同行，而不更改隔离级别。

Answer 1

我不能理解第二个/第一个事务如何获得X锁，而另一个事务已经在某一行上获得了它。

这就是数据库及其性能背后的魔力。锁可以在不同的级别上发布，如果第二个事务没有使用表扫描，它可以在不与第一个事务冲突的情况下发布X锁。使用索引和表扫描进行搜索的update记录可能没有发生，因此表中可能有多个并发的X锁。

我读到，在更新查询时，第一个U锁被应用，然后被升级为X锁，用于特定的更新行。

不是的。更新应该直接在记录上使用X锁。U锁必须由读查询强制执行，读查询读取要更新的数据(这就是@Marc在他的评论中提到的)。正如你已经知道的，EF不支持这一点，因为它不能使用提示。