Question

起初这看起来很容易，但我知道的一切似乎又错了。

看看PAQ的共识似乎是EXEC没有启动隐式事务，你可以测试一下：

create procedure usp_foo
as
begin
  select @@trancount;
end
go

exec usp_foo;

返回0。

如果您使用T-SQL调试器来逐步执行此操作@@事务实际上是根据手表在程序内部1，尽管它确实返回0 ...

所以我认为这是调试器的副作用，但后来我编写了一些代码来测试它，在表中进行更新，然后选择max（id），经典：

create table nextid
(
  id int
)

insert into nextid values (0)

create procedure nextid
as
BEGIN
  UPDATE nextid set id = id + 1
  select max(id) from nextid
END

所以我希望这能给出重复的id并行执行2个更新可以在2选择获取最后一个id并返回相同的值之前完成，但试试我可能从多台机器上击中它我不能让它破坏。当监视机器上的锁和事务时，它报告exec正在事务中发生，重要的是，exec中的所有语句都被视为一个工作单元/一个事务。

我会理解更新是否在事务中并且这是锁定的原因，但锁定似乎一直保持到选择之后。

如果我使用分析器跟踪，我可以看到为EXEC语句的整个执行提供了一个事务ID，并且事务ID不是0，正如我在执行时所期望的那样......

有人可以向我解释我在哪里错过了情节，或者我错了，实际上生成ID是安全的吗？

Answer 1

您的测试必须为您提供正确的结果，因为您没有足够快速调用这两个语句之间的第二次调用。尝试添加延迟，您可以看到测试将开始失败。

CREATE TABLE NextID
(
    ID int
)
GO

INSERT INTO NextID VALUES (0)
GO

CREATE PROC GetNextID
AS
BEGIN
    UPDATE NextID SET ID = ID + 1
    WAITFOR DELAY '00:00:05'
    SELECT Max(ID) FROM NextID
END

发出EXEC GetNextID并在其他会话中尽快发出另一个EXEC GetNextID。大约5秒后，两个EXEC都会返回相同的结果，即不正确的值。现在将SP更改为

CREATE PROC GetNextID
AS
BEGIN
    BEGIN TRAN

    UPDATE NextID SET ID = ID + 1
    WAITFOR DELAY '00:00:05'
    SELECT Max(ID) FROM NextID

    COMMIT TRAN
END

并重复上述测试。你会看到两个调用都会返回正确的值。另外第二次调用（如果尽快发出）将在大约10秒内返回结果，因为UPDATE被阻止并且必须等待5秒（对于第一次调用COMMIT）然后它自己的5秒等待。

EXEC声明和交易范围

1 个答案: