为什么以及何时在Spring事务隔离级别中使用未提交的读隔离级别

Question

这可能是一个非常普遍的问题。但是，我仍然无法找到合适的解决方案/答案，何时以及为什么要使用READ未提交隔离级别。大多数文章和spring说，最有效的方法是使用SERIALIZABLE。在这种情况下，为什么spring事务管理会出现读未提交和读提交隔离级别，如果它们没有效率的话。

我希望至少在这里我能得到答案。

提前感谢

Answer 1

我首先要说的是，我确实相信，很难遇到这种程度的孤立是必要的。大多数情况下，您希望从可重复阅读或SERIALIZABLE开始。

对于运行不同数据库会话但都需要获得“松散”外键的潜在索引的分布式系统，可以(尽管疯狂)使用READ未提交。假设您有两个服务，它们通过REST相互通信，并通过相互协调来管理事务：

1. A插入一行并调用B传递数据库生成的可能密钥，然后等待B
2. B使用A提供的键插入另一个表以检索某些数据，然后提交自己的事务，最后返回A
3. A提交自己的事务

使用的成功

此时，两个表中的行都插入了正确的键。然后，问题转移到了在第(3)步出错的极少数情况下。

除其他外，我认为密钥不应该由数据库生成.但是对于现有的系统，您不一定有决定在哪里生成密钥的自由，也没有重新实现某些东西的自由，即使您对实现有多么糟糕感到震惊。

READ的一种可能用法是，软件可以公开每个用户一个数据库会话，同时希望用户能够刷新内容并查看由不同事务生成的新数据。一个很好的例子是数据库管理前端(、蟾蜍、松鼠等等)。

下面的链接更详细地解释了如何在行业中使用这些隔离级别。为了便于参考，这里还复制了一段摘录：

http://www.dbta.com/Columns/DBA-Corner/The-Danger-of-Dirty-Reads-98511.aspx

读取数据库数据的

程序可以访问许多行，因此容易出现并发问题。为了解决这个问题，大多数主要的RDBMS产品都支持通读锁，也称为“脏读”或“未提交读”，以帮助克服并发问题。当使用未提交的读取(UR)时，应用程序可以访问已更改但尚未提交的数据。脏读取功能通常使用隔离级别实现，但DBMS供应商的精确命名和实现有所不同。

使用脏读取的程序将读取数据而不使用锁。这使应用程序能够在操作表时读取表中包含的数据。它通常会提高数据的性能和可用性，因为在处理过程中没有调用锁定机制。

..。

有几种特殊情况，在这些情况下，脏读功能可能是有意义的。考虑以下情况：

• 访问对于本质上基本上是静态的引用、代码或查找表是必需的。由于数据的非易失性，脏读取与大多数情况下的正常读取没有什么不同。在这些情况下，当代码数据被修改时，任何读取数据的应用程序都必须对大量数据执行最小(如果有的话) problems.
• Statistical处理。例如，您可能希望确定某一薪资范围内女性雇员的平均年龄。未提交的读取对平均多行的影响可能是最小的，因为单个值的更改可能不会对数据仓库环境中的result.
• Dirty读取产生很大的影响。数据仓库用于在线分析处理，除周期性数据传播和/或复制外，访问是只读的。在只读环境中，未提交的读取是完美的，因为它几乎不会造成任何损害，因为数据通常不会改变。在那些罕见的情况下，当一个表或一组表仅由单个用户使用时，UR可以有很大的意义。如果只有一个人可以修改和访问数据，那么只有在被访问的数据已经不一致的情况下，锁定才会添加overhead.
• Finally，，使用脏读访问information.

几乎不会造成什么危害。

脏读取功能可以缓解并发问题，并在非常特定的情况下提供更快的性能。一定要理解UR隔离级别的含义以及它可能导致的“问题”，然后才能在您的生产应用程序中直接实现它。