使用 TransactionScope 不会重新种子标识列

Question

我已开始使用 TransactionScope 来帮助我的设备测试，以便将我的测试数据库恢复到之前的状态。将其与 SpecFlow 一起使用，我有一个如下所示的基类：

public class TransactionScopedFeature
{
    private TransactionScope Scope { get; set; }

    [BeforeScenario]
    public void BaseSetup()
    {
        this.Scope = new TransactionScope(TransactionScopeOption.RequiresNew);
    }

    [AfterScenario]
    public void BaseCleanup()
    {
        if (this.Scope != null)
        {
            this.Scope.Dispose();
        }
    }
}

上述所有工作都有效，因为当我将记录添加到数据库时，当我在测试完成后查询表时，这些表是空的。很棒的东西，而且确实非常聪明！

我的问题与这些表中的标识列有关。我注意到，当我多次运行测试时，测试表的 ID 列增加 1。我假设由于 TransactionScope 会回滚更改，因此身份种子也会回滚。

我的这个假设是错误的吗——数据库就是这样工作的吗？如果是这种情况，我还可以在执行此操作的每个场景之前运行一个 SQL 脚本：

DBCC CHECKIDENT ('dbo.Items', reseed, 0)

我只是想检查一下，以防万一做错了什么，或者这是正常的数据库行为。

干杯。 贾斯。

Answer 1

标识列的种子值不会随 SQL Server 中事务的其余部分一起回滚。

这是设计使然，以便在整个事务持续时间内不必在计数器上放置独占锁以获取身份。

Answer 2

回滚后重新播种身份可能非常危险：如果另一个事务插入记录，就会发生身份冲突。

例如

1. 你启动一个事务
2. 你在表t中插入一条记录：identity字段设置为10
3. John，在另一个并发客户端在表t中插入一条记录。由于第一个事务尚未提交或回滚，因此 John 的事务的标识字段设置为 11
4. John 提交了他的事务。存储 id = 11 的记录
5. 您回滚事务
6. 您将身份重新设置为之前的值，即 9
7. 您插入 2 条新记录。第二个的 id = 11，会发生身份冲突。

这种情况尤其可能发生在您的 unit 集成测试并行运行时（这是 NCrunch 中非常常见的行为）。

经验法则：回滚后不要重新播种

另外，请参阅 marc_s 给 这个问题