此 UPDATE 语句中是否存在可能的竞争条件？答案

【问题标题】：Is there a possible race condition in this UPDATE statement?此 UPDATE 语句中是否存在可能的竞争条件？
【发布时间】：2011-04-29 02:39:12
【问题描述】：

我正在编写一个同步器软件，它将获取一个数据库中的所有更改并将它们同步到另一个数据库。为此，我在表格T 中添加了两列：

alter table T add LastUpdate rowversion, LastSync binary(8) not null default 0

现在我可以轻松地选择自上次同步以来发生变化的所有行：

select * from T where LastUpdate > LastSync

但是在执行同步之后，我应该使两个字段相等。但是更新行也会更新时间戳，所以我必须这样做：

update T set LastSync=@@DBTS+1 where ID=@syncedId

但我想知道 - 这会一直有效吗？如果我读取了@@DBTS 的值，然后另一个用户在我的行被提交之前设法在某处插入/更新了一行怎么办？这是有风险的代码吗？如果是的话 - 怎样才能做得更好？

【问题讨论】：

【解决方案1】：

将“LastSync”存储在与真实数据相同的表中可能根本不是一个好主意。尝试将其存储在另一个没有行版本的表中。这样您就可以避免“更新行也会更新时间戳”的问题。

您的同步器软件可以这样工作：

在同步运行时修改的条目将具有比 max() 查询更高的 rowversion 值。下次调用同步器时，它们将被同步。

【讨论】：

【解决方案2】：

如果您在 Serializable 事务中运行此操作，则其他读取/写入操作将无法影响这些表。

RepeateableRead 也可以完成这项工作...

【讨论】：

表格 - 是的。但是@@DBTS 的值呢？这不存储在任何表中！
@Vilx 如果您在同步期间使用排他表锁，那么@@DBTS 是否被另一个表中的事件递增可能并不重要。
@Martin Smith - 但@@DBTS 对于整个数据库来说是全局的。为什么没关系？如果我为 LastSync 字段获得一个（旧）值，而为 LastUpdate 字段获得一个新值，我的同步将被破坏。
@Vilx 好吧，如果您更新表并且 @@DBTS 的值为 10，那么另一个表会更新几行，使 @@DBTS 的值等于 12，您最终会存储 12在LastSync 字段中，为什么这是个问题？下次您进行同步时，您仍在寻找 LastUpdate > LastSync 所在的行。
@Martin Smith - 问题是反过来。 LastUpdate 获得之后 LastSync 的值。否则，我首先不需要在查询中使用 +1。