0

我遇到了一个有趣的场景。使用实体框架中可用的 context.database.sqlquery 我正在调用存储过程来更新字段。

在管理工作室中直接调用该过程时，在编辑两个或更多项目时不会发生死锁。

当使用 context.database.sqlquery 调用相同的存储过程时，在编辑两个或多个项目时会遇到解除锁定。

我找到了一种方法来纠正这个问题，但我不明白为什么从框架调用该过程会导致死锁。所以我想我会问。

--Create a temp table to hold items based on userid
CREATE TABLE #tableA
(   
    [Id] int identity (1,1),
    [Item_Id] int
)

INSERT INTO #tableA ([Item_Id]) SELECT [Id] FROM [Items] WHERE [UserId] = @UserId

--All of the other processing is omitted for brevity

--Based on final processing above update the IsActive flag on the Items table
UPDATE i
SET [IsActive] = 0
FROM #tableA ta INNER JOIN [Items] i ON ta.[Item_Id] = i.[Item_Id]
WHERE [IsActive] = 1

同样，我有一个可行的解决方案，只是想了解为什么在 EF 中会发生死锁，而不是在直接调用过程时发生死锁。

顺便说一句，解决方案是将 IsActive 位添加到临时表并最初填充它，然后在更新语句中的联接上，我在 where 子句中使用了临时表 isactive 位置。

--Create a temp table to hold items based on userid
CREATE TABLE #tableA
(   
    [Id] int identity (1,1),
    [Item_Id] int,
    [IsActive]
)

INSERT INTO #tableA ([Item_Id], [IsActive]) SELECT [Id], [IsActive] FROM [Items] WHERE [UserId] = @UserId

--All of the other processing is omitted for brevity

--Based on final processing above update the IsActive flag on the Items table
UPDATE i
SET [IsActive] = 0
FROM #tableA ta INNER JOIN [Items] i ON ta.[Item_Id] = i.[Item_Id]
WHERE ta.[IsActive] = 1
4

0 回答 0