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