java - 为简单的 Pojo 数据对象启用自动提交？

Question

在我的应用程序中，我将底层存储对象隐藏在接口(interface)后面，允许我随意切换存储。

问题是，在测试 Hibernate 时，Hibernate 似乎非常面向事务。我能找到的关于该主题的所有内容(主要是 their official docs )都表明自动提交不好，应该很少使用。然而，我的整个应用程序并不是围绕 Hibernate 编写的，而是围绕接口(interface)编写的。这意味着从数据库获取数据发生在一种方法中(例如工厂中的 getObjects())，而不是事务。

既然我已经抽象了存储实现，那么自动提交是正确的解决方案吗？或者有其他选择吗？

Answer 1

使用自动提交，并不意味着不再使用事务来访问数据。它只是意味着每个语句现在都在它自己的事务中执行。事务开始和终止的确切实例在 JDBC 规范中定义。为了简洁起见，这通常取决于所执行语句的性质。

我不确定您的设计是如何实现的，但非事务系统通常会遇到三个问题。使用自动提交可能会重新引入一个或多个这些问题。

脏读

考虑应用程序中的一个线程 A，它将读取实体并更新它，但不提交新值。考虑另一个线程 B 读取同一实体并查看更新后的值。如果线程A要回滚它的更改，或者未能提交更新的值，那么B本质上是在使用脏值，因为它执行了脏读。

它自己的自动提交不会导致脏读。但是，如果您有一系列最初在单个事务中执行的数据库读写操作，则在每次读/写操作后提交序列将导致不同事务中的脏读，因为当前事务可能会简单地回滚变化。

不可重复读取

在事务上下文中，在事务上下文中读取同一实体(记录)两次，并且在第二次读取时看到不同的值被视为不可重复读取。当不同的事务提交其更改并且正在进行的事务读取新值时，就会发生这种情况。

使用自动提交(或者更确切地说，在两个不同的事务中执行读取操作)很可能会导致不可重复读取，因为同一线程中的两个读取操作将在不同的事务上下文中执行，从而导致第二个读取并查看提交的值(来自不同线程中的事务)。

幻读

与不可重复读取非常相似，但又不完全一样。在这种情况下，执行第二次读取的执行线程将看到新记录形式的附加数据(而不是更新的数据)。

同样，出于同样的原因，使用自动提交很可能会导致应用程序中出现幻读。

这些问题还取决于所采用的数据库事务隔离级别，但最终当使用 ORM 框架时，标记事务的开始和结束将留给应用程序开发人员。虽然各个读写操作可以通过数据库相互隔离，但开发人员需要确保工作发生在事务上下文中。使用自动提交会更改每个操作的事务上下文。

TLDR

在执行事务 Activity 时使用自动提交意味着，如果“业务事务上下文”期间发生故障，则无法回滚到安全状态。顺便说一句，正是由于这个原因，在 JDBC 中执行批量更新时应禁用自动提交。当真正需要在批处理结束时提交时，使用自动提交将强制对批处理中的每个更新进行提交。

我建议阅读这本书Java Transaction Design Strategies (作为免费电子书提供)以进一步了解如何使用交易。