Блокируют ли хранимые процедуры таблицы / строки?

Question

Довольно простой вопрос.В SQL 2008, если у меня есть хранимая процедура (см. Ниже), могу ли я подвергнуться риску состязания между первыми двумя операторами или хранимая процедура блокирует то, к чему она прикасается, как это делают транзакции?

ALTER PROCEDURE [dbo].[usp_SetAssignedTo] 
    -- Add the parameters for the stored procedure here
    @Server varchar(50), 
    @User varchar(50),
    @UserPool varchar(50)
AS
BEGIN
    SET NOCOUNT ON;
    Declare @ServerUser varchar(50)

    -- Find a Free record
    SELECT top 1 @ServerUser = UserName 
    from ServerLoginUsers
    where AssignedTo is null and [TsServer] = @Server

    --Set the free record to the user
    Update ServerLoginUsers
    set AssignedTo = @User, AssignedToDate = getdate(), SourcePool = @UserPool
    where [TsServer] = @Server and UserName = @ServerUser

    --report record back if it was updated. Null if it was not available.
    select * 
    from ServerLoginUsers 
    where [TsServer] = @Server 
        and UserName = @ServerUser 
        and AssignedTo = @User
END

Answer 1

Вы можете получить условие гонки.

Это можно сделать одним утверждением:

• Вы можете назначить в ОБНОВЛЕНИИ
• Подсказки блокировки позволяют другому процессу пропустить эту строку
• Предложение OUTPUT возвращает данные вызывающей стороне

Попробуйте это ... (редактировать: блокировка снята)

Update TOP (1) ServerLoginUsers WITH (ROWLOCK, READPAST)
OUTPUT INSERTED.*
SET
   AssignedTo = @User, AssignedToDate = getdate(), SourcePool = @UserPool
WHERE
   AssignedTo is null and [TsServer] = @Server   -- not needed -> and UserName = @ServerUser

Если нет, вам может потребоваться отдельный выбор

Update TOP (1) ServerLoginUsers WITH (ROWLOCK, READPAST)
SET
    -- yes, assign in an update
   @ServerUser = UserName,
   -- write
   AssignedTo = @User, AssignedToDate = getdate(), SourcePool = @UserPool
OUTPUT INSERTED.*
WHERE
   AssignedTo is null and [TsServer] = @Server   -- not needed -> and UserName = @ServerUser

SELECT ...

См., Пожалуйста, больше: Состояние гонки очереди процесса SQL Server