为什么在Hibernate中不建议使用“hibernate.connection.autocommit = true”？

Posted 2021-04-24

在Hibernate API中，有一个属性hibernate.connection.autocommit，可以设置为true。

但是在API中，他们提到不建议像这样设置它：

为JDBC池连接启用自动提交（不建议这样做）。

为什么不推荐？将此属性设置为true会产生什么不良影响？

答案

默认情况下，自动提交值为false，因此需要显式提交事务。这可能是更改没有反映在数据库中的原因，否则可以尝试刷新以在提交之前强制执行更改。

当你关闭会话时，它将隐式地在数据库中提交[取决于实现]。

当您有级联事务并需要回滚原子性时，您需要控制事务，在这种情况下，自动提交应该是false。

将autocommit设置为true或显式处理事务。

Here是一个很好的解释。

Hibernate forum与此有关。

Stackoverflow question就可以了。

另一答案

我的理解是，如果Hibernate自动提交，那么部分失败的刷新将不会回滚。你将有一个不完整/破碎的对象图。

如果你想要一个自动提交连接的东西，你可以随时打开一个新创建的Session以获取基础JDBC连接，setAutocommit(true)，通过JDBC API，setAutocommit(false)完成工作，并关闭会话。我不建议在已经做过任何事情的Session上这样做。

另一答案

所有数据库语句都在物理事务even when we don’t explicitly declare transaction boundaries（BEGIN / COMMIT / ROLLBACK）的上下文中执行。

如果您没有声明事务边界，那么每个语句都必须在单独的事务中执行。这甚至可能导致每个语句打开和关闭一个连接。

将服务声明为@Transactional将为您提供整个事务持续时间的一个连接，并且所有语句都将使用该单个隔离连接。这比首先不使用显式事务更好。在大型应用程序上，您可能有许多并发请求，而reducing database connection acquiring request rate肯定会提高您的整体应用程序性能。

所以经验法则是：

1. 如果您具有只执行一个查询的只读事务，则可以为这些事务启用自动提交。
2. 如果您的事务包含多个语句，则需要禁用自动提交，因为您希望所有操作都在一个工作单元中执行，并且您不希望对连接池施加额外的压力。

另一答案

不要使用session-per-operation反模式：不要在单个线程中为每个简单的数据库调用打开和关闭Session。数据库事务也是如此。应用程序中的数据库调用使用计划的序列进行;它们被分为原子工作单元。这也意味着每个SQL语句在应用程序中无效后自动提交，因为此模式用于临时SQL控制台工作。 Hibernate禁用或期望应用程序服务器立即禁用自动提交模式。数据库事务绝不是可选的。与数据库的所有通信都必须在事务内部进行。应该避免读取数据的自动提交行为，因为许多小事务不可能比一个明确定义的工作单元执行得更好。后者也更易于维护和扩展。

find more information on this topic