问题标签 [isolation-level]

我是构建基于 ADO.NET 的网站的团队的一员。我们有时有几个开发人员和一个自动化测试工具同时工作一个数据库的开发副本。

我们使用快照隔离级别，据我所知，它使用乐观并发：而不是锁定，它希望做到最好，如果在受影响的行已被另一方更改期间尝试提交事务，则会引发异常交易。

要使用快照隔离级别，我们使用：

在 C# 中：

请注意，IsolationLevel Snapshot 与 ReadCommitted Snapshot 不同，我们也尝试过，但目前没有使用。

当其中一位开发人员进入调试模式并暂停 .NET 应用程序时，他们将在调试时保持与活动事务的连接。现在，我希望这不是问题——毕竟，所有事务都使用快照隔离级别，所以当一个事务暂停时，其他事务应该能够正常进行，因为暂停的事务没有持有任何锁。当然，当暂停的事务完成时，很可能会检测到冲突；但只要其他开发人员和自动化测试可以不受阻碍地进行，这是可以接受的。

然而，在实践中，当一个人在调试时暂停事务时，尽管使用了快照隔离级别，但尝试访问相同行的所有其他数据库用户都会被阻止。

有谁知道为什么会发生这种情况，和/或我如何才能实现真正的乐观（非阻塞）并发？

决议（对我来说是一个不幸的决议）：Remus Rusanu指出作家总是会阻止其他作家；这得到了MSDN的支持——它并没有说出来，但只提到了避免读写器锁。简而言之，我想要的行为没有在 SQL Server 中实现。

SQL Server 2005 中事务隔离级别的范围规则是什么？我知道不同级别的含义，但不知道如何在手动运行的脚本之外正确应用它们。我找不到生产质量代码的实际使用指南。

显然，当您使用这样的命令时，范围就开始了：

但它在哪里结束？如果我在存储过程中设置 iso 级别，然后该 proc 调用另一个，嵌套 proc 是否继承它？更好的是，如果我升级嵌套 proc 内的 iso 级别，它会执行回调用 proc 吗？像 BEGIN TRAN、ROLLBACK 和 COMMIT 这样的事务命令有什么不同吗？

当应用程序或代理作业调用存储过程时，隔离级别更改是否以某种方式持续存在？我总是必须在每个过程结束时恢复到默认的 READ COMMITTED 吗？

我会在不同的情况下对其进行测试，但我不知道如何读取当前隔离级别设置的内容。

我想知道达到事务隔离级别的最佳方法是什么？ 这是可用隔离级别的一个很好的链接。

Blockquote 如果有人可以解释事务的各种隔离级别，那就太好了

对于同一个 ADO.Net 语句，我想确保我对隔离级别和锁的理解是正确的。

1. 在默认 SQL Server 隔离级别（已提交读）下，读取每一行后，该行将解锁；

2. 如果我将隔离级别提高到可重复读取，锁（在整个表上？还是其他级别的锁？）将一直保持到 while 循环结束？

例如：

提前谢谢，乔治

我正在从以下链接研究 SQL Server 2008 的快照隔离级别。我的困惑是，

http://msdn.microsoft.com/en-us/library/ms173763.aspx

1. 提到“当前事务开始后其他事务所做的数据修改对当前事务中执行的语句不可见。” -- 似乎其他事务提交的数据对当前快照隔离级别事务不可见；

2. 提到“在 SNAPSHOT 隔离级别下运行的事务可以查看该事务所做的更改。” -- 似乎其他事务提交的数据对当前快照隔离级别事务是可见的。

好像1和2有冲突？任何意见？

提前谢谢，乔治

我有一个在 Tomcat 6 中运行的 Web 应用程序，并且我设法将其配置为使用内置的 DBCP 连接池，并且一切运行良好，但是我怀疑它在数据库上以错误的隔离级别运行。我希望它在未提交的读取中运行，但我认为它在已提交的读取中运行并且不知道如何设置它。

这是我的上下文的 XML 文件：

这是用于获取数据库连接的 Java 方法。

获得连接后，getDatabaseConnection()我意识到我可以手动设置隔离级别，conn.setIsolationLevel( Connection.TRANSACTION_READ_UNCOMMITTED )但这感觉不对，因为它要么涉及将隔离级别硬编码到 Java 中，要么在每次需要新连接时执行对 servlet 上下文的查找.

我可以以某种方式在上下文 XML 中定义它，还是有更好的方法我不知道？

我们有一位客户在使用我们的数据库应用程序时遇到了一些阻塞问题。我们要求他们运行 Blocked Process Report 跟踪，他们给我们的跟踪显示 SELECT 和 UPDATE 操作之间发生了阻塞。跟踪文件显示以下内容：

• 在不同的隔离级别上执行相同的 SELECT 查询。一个跟踪显示了 Serializable IsolationLevel，而后面的跟踪显示了 RepeatableRead IsolationLevel。我们在执行查询时不使用显式事务。
• UPDATE 查询正在使用 RepeatableRead 隔离级别执行，但被 SELECT 查询阻止。这是意料之中的，因为我们的更新被包装在一个具有可重复读取的 IsolationLevel 的显式事务中。

所以基本上我们不知道为什么 SELECT 查询的 Isolation Level 不会是默认的 ReadCommitted IsolationLevel，但更令人困惑的是，为什么查询的 IsolationLevel 会随着时间而改变？只有一个客户看到此行为，因此我们怀疑这可能是数据库配置问题。

有任何想法吗？

提前致谢，

格雷厄姆

我有一个从 clickview 到 sql2005-server 的 oledb 连接，我希望这个连接使用未提交读取的事务隔离级别。我的第二选择是将其设置在用户身上。我怎样才能做到这一点？

考虑一个具有 3 列的表：ID（唯一，取自 Oracle 序列）、CATEGORY 和 CODE（对最后两列没有限制）。

每个类别都有多个附加代码，但代码在该类别中必须是唯一的。例子：

第三个不行，因为我们已经有了类别 1 的代码 Y。

现在考虑一个在插入之前运行的触发器，并检查要插入的值是否正常。也就是说，对于正在插入的记录，触发器读取类别，然后从表中读取具有该类别的所有代码，如果必须插入的记录中的代码已经存在，则引发异常，以便记录未插入。

我的问题是，如果事务隔离级别是READ_COMMITED并且几乎完全相同的时间在两个不同的事务中执行了两个插入但事务稍后提交，那么触发器将在表中“看到”什么？

例子：

(1) 最初，表格如下所示：

(2) 有两个事务 T1 和 T2（READ_COMMITED两者的隔离级别）；

(3) 两个事务都想插入category = 1 和code = Y；

(4) T1 执行插入，执行触发器。表中没有Y所以可以插入；

(5) T2执行插入，触发执行。表中没有Y（T1还没有提交）所以可以插入；

(6) T1 提交，表格现在看起来像这样：

(7) T2 现在提交。这里会发生什么？我得到一个错误并且没有插入记录还是得到下表：

？！

触发器“看到”了什么以及插入会发生什么？

简单的问题？

为什么READ_COMMITTED_SNAPSHOT默认不开启？

我猜是向后兼容性、性能还是两者兼而有之？

[编辑]请注意，我对与 READ_COMMITTED 隔离级别相关的效果感兴趣，而不是快照隔离级别。

为什么这是一个重大更改，因为它拥有更少的锁，并且仍然不读取未提交的行？