所有数据库语句都在物理事务的上下文中执行，即使我们没有显式声明事务边界(Begin/Commit/Rollback)也是如此。
如果不声明事务边界，则必须在单独的事务中执行每条语句。这甚至可能导致每个语句打开和关闭一个连接。
将服务声明为@Transaction将为您提供整个事务持续时间的一个连接，并且所有语句都将使用该单个隔离连接。这比一开始就不使用显式事务要好得多。在大型应用程序中，您可能有许多并发请求，降低数据库连接获取请求率肯定会提高应用程序的整体性能。
因此，经验法则是：
1.如果您的只读事务只执行一个查询，则可以为这些事务启用自动提交。
1.如果您的事务包含多条语句，则需要禁用自动提交，因为您希望所有操作都在单个工作单元中执行，并且不想给连接池带来额外的压力。

默认情况下，自动提交值为FALSE，因此需要显式提交事务。这可能是更改不会反映在数据库中的原因，否则可以尝试刷新以在提交之前强制更改。
当您关闭会话时，它将在数据库中隐式提交[取决于实现]。
当您有级联事务并需要回滚以实现原子性时，您需要控制事务&在这种情况下，自动提交应该为FALSE。
要么将自动提交设置为True，要么显式处理事务。
Here是对此的一个很好的解释。
Hibernate forum与此相关。
Stackoverflow question在上面。

我的理解是，如果Hibernate自动提交，则中途失败的刷新将不会回滚。您将得到一个不完整/损坏的对象图。
如果您希望某个连接启用自动提交，则始终可以解开新创建的Session以获得底层JDBC连接setAutocommit(true)，通过JDBC API setAutocommit(false)完成工作，然后关闭会话。我不建议在已经做了任何事情的Session上这样做。

不要使用每个操作的会话反模式：不要为单个线程中的每个简单数据库调用打开和关闭会话。数据库事务也是如此。应用程序中的数据库调用是使用计划的顺序进行的；它们被分组为原子工作单元。这也意味着，在每个单独的SQL语句之后自动提交在应用程序中是无用的，因为该模式旨在用于临时的SQL控制台工作。Hibernate立即禁用或期望应用程序服务器禁用自动提交模式。数据库事务从来都不是可选的。与数据库的所有通信都必须在事务内部进行。应该避免读取数据的自动提交行为，因为许多小事务不太可能比一个明确定义的工作单元执行得更好。后者也更具可维护性和可扩展性。
find more information on this topic