EXEC声明和交易范围

如何解决EXEC声明和交易范围

| 一开始这似乎很容易，但是我所知道的一切似乎又是错误的。查看PAQ的共识似乎是EXEC不会启动隐式事务，您可以测试这样做：

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

exec usp_foo;

返回0。但是，如果您使用T-SQL调试器逐步完成此操作，根据@watch，实际上@@ Transaction在过程中实际上为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语句的整个过程中都提供了事务ID，并且事务ID不为0，正如我在执行时所期望的那样。有人可以向我解释我在哪里丢失情节吗？或者我错了，实际上生成这样的ID是安全的吗？

解决方法

您的测试必须给您正确的结果，因为您不够快，无法调用这两个语句之间的第二个调用。尝试添加延迟，您会看到测试将开始失败。

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，并尽快从另一个会话发出issue3ѭ。大约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声明和交易范围

如何解决EXEC声明和交易范围

解决方法

相关推荐