通常，Hibernate中的事务与JDBC中的事务几乎相同。从中获取Connection时，DataSource它默认为autocommit =
true，因此对于已更改为autocommit = false的事务。这样，仅在显式提交时（而不是每次执行更新时）才在数据库中进行更改。

Hibernate
Session做了很多事情，但是在这种情况下，它的功能是作为一级缓存。它使用称为“事务后写”的概念来提高性能，以使该缓存中的更改排队，并仅在必要时将其推送到数据库。因此，例如，如果您检索一个持久性实例并在一个复杂的多方法工作流中对其进行更改，其中每个方法可能不进行任何更改或进行多次更改，则只需要一个更新SQL语句，因此Hibernate会等到有必要将它们聚合在一起。但是，这与您是否正在事务中运行无关-
这种情况总是会发生。

会话高速缓存和活动事务在一起的位置在活动事务期间处于刷新状态。由于Hibernate会等待尽可能长的时间来刷新更改，因此，如果您不在事务中并进行刷新，则更改将立即在数据库中持久化。因此，这是一种性能优化，可减少数据库写入次数。但是，如果您正在事务中并且刷新了会话，则确实会将更改推送到数据库。但是数据库将更改保留在其事务队列中。因此，即使它们在数据库中，它们也对其他连接不可见，直到您提交事务为止。

理想情况下，不会有任何显式的刷新，并且事务提交将在提交之前触发刷新，这既可以最大程度地减少您需要进入数据库的次数，又可以使未提交的更改对其他调用者不可见。但是您可以根据需要多次冲洗。

查询将导致Hibernate代表您自动刷新的一件事。就像我说的，您可以对持久性实例进行许多更改（甚至删除它们），它们只会在会话缓存中排队。但是，如果您运行查询（动态查找器，条件，HQL等），则Hibernate无法知道排队的更改是否会影响您的查询。因此，它是悲观的，会刷新以确保查询的所有内容都一致。数据库将使用已刷新但未提交的数据进行查询，并返回预期结果。这就是我们建议您withNewSession在自定义域类验证器中进行查询时使用该方法的原因，这样您就不会在验证过程中刷新当前会话，而这会导致奇怪的行为。