Question

考虑我的问题"Should snapshot transaction isolation be avoided in client ADO.NET applications? then, what was its main purpose?"，
SQL Azure数据库严格限制下的目的/原理/意义是什么：

"Both the READ_COMMITTED_SNAPSHOT and ALLOW_SNAPSHOT_ISOLATION database options are set to ON in SQL Azure Database. Because SET in the ALTER DATABASE Transact-SQL statement is not supported, these database options cannot be changed"

后者也不是与SQL Azure数据库Connection Constraints：

相矛盾

“由于以下条件，您与服务的连接可能会被关闭：
- 资源使用过多
- 闲置30分钟或更长时间的连接“

Answer 1

SNAPSHOT隔离绝对是最好的选择。您提供的所有链接唯一正确的缺点是overhead of row versioning。为了使用SNAPSHOT隔离，绝对不需要'持久'数据库连接。你链接的Dan Guzman的文章充其量是误导性的。虽然它没有做出错误的主张，但它制定问题的方式导致错误的结论。

您始终可以使用乐观并发模型开发应用程序以进行更新：

读：

SELECT
      ContactName,
      ContactTitle
FROM dbo.Suppliers
WHERE SupplierID = @SupplierID;

写：

UPDATE dbo.Suppliers
SET
      ContactName = @NewContactName,
      ContactTitle = @NewContactTitle
WHERE
      SupplierID = @SupplierID AND
      ContactName = @OriginalContactName AND
      ContactTitle = @OriginalContactTitle;

IF @@ROWCOUNT = 0 --a zero rowcount indicates data was deleted or changed
BEGIN
      RAISERROR ('Contact information was changed by another user', 16, 1);
END;

绝对不要求Read和Write应该在同一个连接中发生。绝对地，肯定的是，您可以在SNAPSHOT隔离下进行读写，并获得乐观的并发控制。本文给出了依赖于SNAPSHOT隔离而不是乐观并发控制的并发性示例，但当然这样做它已经静默更改了应用程序的所有内容：在第二个示例中读取和Write 必须出现在同一个事务中，因此不再是第一个例子的情况（不能是典型的读取显示 - 后 - 更新为第一个场景。）

所以不，SQL Azure不会在脚下射击。 SNAPSHOT隔离也不需要持久连接。 ASP.Net也不能使SNAPSHOT隔离无法使用。我恐怕我不得不说你需要更好地过滤你的输入。对你在intertubes上发现的内容进行更长时间的记忆，假设一切都是错误的，直到被证明正确，坚持官方产品规范并避免博客，专家或论坛/答案网站，如stackoverflow ......

是不是SQL Azure限制了自己的脚步？

1 个答案: