在Hibernate API中，有一个属性hibernate.connection.autocommit可以设置为true。
但是在API中，他们提到不建议像这样设置它：
为JDBC池连接启用自动提交（不是 推荐）。
为什么不推荐？ 将此属性设置为true会产生什么不良影响？
答案 0 :(得分：13)
默认情况下，autocommit值为false，因此需要显式提交事务。这可能是更改没有反映在数据库中的原因，否则可以尝试刷新以在提交之前强制执行更改。
当您关闭会话时，它将隐式地在数据库中提交[取决于实现]。
当你有级联交易＆amp;需要回滚原子性，你需要控制交易＆amp;在这种情况下，自动提交应该是假的。
将autocommit设置为true或显式处理事务。
Here是一个很好的解释。
Hibernate forum与此相关。
答案 1 :(得分：6)
我的理解是，如果Hibernate自动提交，那么部分失败的刷新将不会被回滚。您将拥有一个不完整/已损坏的对象图。
如果您希望与某个东西进行自动提交连接，您可以随时解包新创建的Session以获取基础JDBC连接，setAutocommit(true)，通过JDBC API执行您的工作，{{ 1}}，然后关闭会话。我不建议在已经完成任务的setAutocommit(false)上执行此操作。
答案 2 :(得分：5)
所有数据库语句都在物理事务的上下文中执行even when we don’t explicitly declare transaction boundaries（BEGIN / COMMIT / ROLLBACK）。
如果您没有声明事务边界，那么每个语句都必须在单独的事务中执行。这甚至可能导致每个语句打开和关闭一个连接。
将服务声明为@Transactional将为您提供整个事务持续时间的一个连接，并且所有语句都将使用该单个隔离连接。这比首先不使用显式事务更好。在大型应用程序上，您可能有许多并发请求，而reducing database connection acquiring request rate肯定会提高您的整体应用程序性能。
所以经验法则是：
如果您只有执行一个查询的只读事务，则可以为这些事务启用自动提交。
如果您的交易包含多个语句，则需要禁用自动提交，因为您希望所有操作都在一个工作单元中执行而您不想放置连接池上的额外压力。
答案 3 :(得分：2)
不要使用session-per-operation反模式：不要在单个线程中为每个简单数据库调用打开和关闭Session。数据库事务也是如此。应用程序中的数据库调用使用计划的序列进行;它们被分为原子工作单元。这也意味着每个SQL语句在应用程序中无效后自动提交，因为此模式用于临时SQL控制台工作。 Hibernate禁用或期望应用程序服务器立即禁用自动提交模式。数据库事务绝不是可选的。与数据库的所有通信都必须在事务内部进行。应该避免读取数据的自动提交行为，因为许多小事务不可能比一个明确定义的工作单元执行得更好。后者也更易于维护和扩展。