问题标签 [transaction-isolation]

我正在尝试将 Microsoft SQL Server 2008 R2 中的 SNAPSHOT 事务隔离级别与 Entity Framework 4.0 结合使用。然而，这似乎并不像我最初想象的那么容易。

要使用 SNAPSHOT 隔离级别，必须在数据库中启用它。我已经做到了。我已经使用 SQL Management Studio 测试了 SNAPSHOT 隔离级别在我的数据库上按预期工作。我想使用此隔离级别，因为我希望在不锁定行或整个表的情况下进行一致的读取。所以我的数据库已经准备好让我使用 SNAPSHOT 隔离级别了。到现在为止还挺好。

在我的 repro 应用程序（一个 WPF 应用程序）中，我有一个窗口，可以在其中从单个表中加载一些数据。每次单击按钮时，我一次加载 5 行。这是窗口的 XAML：

这是窗口的代码隐藏：

这里没有什么神奇的事情发生。现在查看视图模型的代码，这是动作发生的地方。

我在这里尝试做的是打开与数据库的连接并保持打开状态。我尝试启动事务并请求 SNAPSHOT 隔离级别。这将允许我一次读取 5 行并获得打开窗口时的行，即使有人会在窗口打开时编辑、删除或插入行。但是，当我使用 SQL Profiler 运行跟踪时，当窗口打开或加载行时没有启动事务，并且没有设置我要求的隔离级别。当窗口打开时，一个连接被打开，Entity Framework 将事务隔离级别设置为 READ COMMITTED，这是默认的隔离级别。如果我使用 TransactionScope 而不是 DbTransaction，也会发生同样的情况（即什么都没有）。

所以我的问题是：如何以 SNAPSHOT 隔离级别启动事务并在我的窗口打开时保持打开状态？事务保持打开是绝对必要的，这样我就可以继续从连接中读取数据，而无需读取其他用户同时添加的行。

我知道我可以使用原始 SQL 命令来做到这一点，但如果可能的话，我想避免这种情况。

旁注：人们对不同的隔离级别有不同的看法，但这个问题不是为了讨论SNAPSHOT隔离级别是否适合这种情况。SNAPSHOT 完美地满足了我们对此任务的业务需求。问题实际上也可能与任何其他隔离级别有关，因为其他隔离级别也不适用于此代码。

我有一个带有主键的简单表。大多数读取操作通过键的确切值获取一行。

每一行中的数据在键顺序中与它之前和之后的行保持某种关系。所以当我插入一个新行时，我需要读取它要进入的 2 行，进行一些计算然后插入。

显然，问题在于，同时另一个连接可能会在同一时间间隔内添加具有键值的行。如果它与第二次插入失败的键值完全相同，我会被覆盖，但如果键值不同但在相同的时间间隔内，则关系可能会被破坏。

解决方案似乎是在我决定添加新行时锁定整个表以进行写入，或者（如果可能的话，我怀疑）锁定键值的间隔。然而，我更希望那时只读事务不会被阻止。

我在客户端程序和 IBM DB2 免费版中使用带有libodbc++ 包装器的ODBC（尽管 DB 选择可能仍会改变）。这就是我想做的事情：

• 以自动提交和默认隔离模式启动连接
• 当需要添加新行时，将 auto-commit 设置为 false 并将隔离模式设置为 serialized
• 读取新键值前后的行
• 计算并插入新行
• 犯罪
• 返回到自动提交和默认隔离模式

这会做这项工作吗？是否允许其他事务同时读取？还有其他/更好的方法吗？

顺便说一句，我没有在 libodbc++ i/fa 中看到指定只读事务的方式。在odbc中可以吗？

编辑：感谢非常有用的答案，我很难选择一个。

考虑到一个论坛表和许多用户同时向其中插入消息，这个事务有多安全？

在这里，我阅读了最后一个 MessageId 并增加了它。我不能使用标识字段，因为它需要为插入组中的每条消息增加（不是每条消息都插入表中。）

我看到与事务隔离级别相关的错误消息。涉及两个表，第一个经常更新，事务隔离级别设置为SERIALIZABLE，第二个在第一个上有外键。

插入或更新第二个表时会出现问题。几个小时后，我收到以下错误消息：

由于更新冲突，快照隔离事务中止。您不能使用快照隔离直接或间接访问数据库“DB”中的表“dbo.first”来更新、删除或插入已被另一个事务修改或删除的行。重试事务或更改更新/删除语句的隔离级别。

插入或更新第二个表时我没有设置事务隔离级别，我也运行了命令DBCC USEROPTIONS它返回 read_committed

我对a之间的关系有点困惑

• 数据库打开会话
• 连接池

详细地说，我将 JDBC 与 Oracle 9i DB 一起使用，并且我还使用连接池来汇集我的连接。

我想知道的是：当我的连接在池中空闲时，它们是否与任何Open Session数据库相关联？所以如果我有 5 个连接在池中闲置，这是否意味着将有 5 个相应的活动会话打开我的数据库？

我打开了两个命令窗口来使用我的数据库（MySQL5）。

下面是我正在使用的表结构（应该注意，我已经通过执行关闭了自动提交set autocommit=0;）：

表结构：

以下是活动顺序：

第 1 步： 在命令窗口 1 中，我执行了以下命令，您还可以看到输出：

第 2 步 在第二个命令窗口中，我触发了下面的命令并且它挂起（似乎等待提交命令是来自上一个窗口的问题）

第 3 步 我转到命令窗口#1，然后执行commit；你可以看到下面的输出：

同时，我可以看到之前挂起的第二个窗口也执行了命令并打印在输出下方：

第 4 步 现在我在第二个窗口中发出 commit 以确保即使在第二个会话中也能正确提交所有更改：

第 5 步 现在，由于两个窗口都发出了提交，我认为一切都很好，两个会话也必须同步，所以我转到第一个命令窗口并发出以下命令：

我很惊讶，因为我City期望值是'Dublin'因为来自第二个命令窗口（即update）的更改已提交Step 4，但我仍在Wil列中City。

我在这里做错了什么？

我们在什么场景下使用SERIALIZABLE隔离级别？我在网站上看到一些答案说，当您希望交易完全隔离时，我们通常会这样做。

我想从你自己的经验中知道的是，当你在你的项目中使用它/或者你已经看到它在其他项目中使用时，其他隔离级别没有满足的具体要求是什么?

从MySQL 文档中并不完全清楚InnoDB 引擎是实现真正的可序列化隔离¹还是快照隔离，这通常也被混淆地称为“可序列化”。哪一个？

如果 MySQL InnoDB 没有，是否有任何完全免费的、生产质量的 RDBMS 可以做到？

¹其中“真正的可序列化隔离”意味着不仅没有按照 SQL 标准的读取异常，而且还没有写入倾斜异常，这里有更详细的解释。

我有一个使用休眠版本 3.6.4 和 c3p0 版本 0.9.1.2 进行连接池的应用程序。我的底层 RDBMS 是 MySql 版本 5.0.67。

我的MySql安装表明默认事务隔离级别是“REPEATABLE-READ”（4）：

我没有在 hibernate.cfg.xml 或我的应用程序中的任何地方更改或配置事务隔离级别。在应用程序中，我使用以下代码打印配置：

我得到以下结果：

所以，我的问题如下：

1. “2”值从何而来？既然默认是 REPEATABLE_READ，为什么getDefaultTransactionIsolation()返回 READ_COMMITTED？
2. hibernate到底使用了什么隔离级别？REPEATABLE_READ 还是 READ_COMMITTED？
3. 我认为当没有设置隔离级别时，hibernate应该使用底层数据库的默认值。这是真的？也许 jbdc 驱动程序实现自己设置了一个默认值，而 hibernate 使用它？

我有一个使用 Seam & Hibernate（JDBC 到 SQLServer）的 Seam Web 应用程序。

它运行良好，但在重负载下（使用 JMeter 进行压力测试），我有一些LockAcquisitionExceptionor OptimisticLockException.

这LockAquisitionException是由SQLServerException “事务（进程 ID 64）与另一个进程在锁定资源上发生死锁并已被选为死锁受害者。重新运行事务”引起的。

然后，我编写了一个接缝拦截器来重新运行此类事务LockAquisitionException：

第一个问题：你认为这个拦截器能正确完成这项工作吗？

通过谷歌搜索并看到Alfresco（这里有一个论坛讨论），Bonita和Orchestra也有一些方法可以重新运行此类事务，并且他们正在捕获更多异常，StaleObjectStateException例如（我的原因OptimisticLockException）。

我的第二个问题如下：对于StaleObjectStateException（“行已被另一个事务更新或删除（或未保存的值映射不正确）”），通常你不能只重新运行事务，因为这是与数据库和@Version字段同步的问题不是吗？例如，为什么 Alfresco 会尝试重新运行由此类异常引起的此类事务？

编辑：由于LockAcquisitionException原因SQLServerException，我查看了网络上的一些资源，即使我应该仔细检查我的代码，它似乎无论如何都会发生......这里是链接：

• 一篇关于这个主题的文章（有评论说它也可能因资源耗尽而发生）
• 另一篇带有子链接的文章：
  • 微软在 support.microsoft.com 上谈论这个
  • 一种分析交易的方法
  • 以及一些减少此类问题的建议

甚至微软也说“虽然死锁可以最小化，但不能完全避免。这就是为什么前端应用程序应该设计成处理死锁的原因。”