JPA /休眠刷新策略初学者指南

介绍

在我之前的文章中，我介绍了实体状态转换 对象关系映射范例。

当刷新当前持久性上下文时，所有管理实体状态转换都将转换为关联的数据库语句。 Hibernate的刷新行为并不总是像人们想象的那么明显。

后写

Hibernate尝试将持久性上下文刷新推迟到最后可能的时刻。 传统上，这种策略被称为事务后写 。

后写与Hibernate刷新更相关，而不是任何逻辑或物理事务。 在事务期间，刷新可能会发生多次。

仅对当前数据库事务可见刷新的更改。 在提交当前事务之前， 其他并发事务看不到任何更改。

持久性上下文（也称为第一级缓存 ）充当当前实体状态转换和数据库之间的缓冲区。

在缓存理论中 ，后写同步要求对缓存进行所有更改，缓存的责任是最终与后备存储同步。

减少锁争用

每个DML语句都在数据库事务中运行。 基于当前数据库事务隔离级别 ，可以为当前选定/修改的表行获取锁（共享或显式）。

减少锁保持时间可以降低死锁的可能性，并且根据可伸缩性理论 ，它可以提高吞吐量。 锁总是引入串行执行，根据阿姆达尔定律 ，最大加速与当前正在执行的程序的串行部分成反比。

即使在READ_COMMITTED隔离级别，UPDATE和DELETE语句也将获得锁。 此行为可防止其他并发事务读取未提交的更改或修改相关行。

因此，延迟锁定语句（UPDATE / DELETE）可能会提高性能，但是我们必须确保数据一致性不会受到任何影响。

批处理

延迟实体状态转换同步还有另一个主要优点。 由于所有更改都被立即清除，因此Hibernate可能会受益于JDBC批处理优化 。

批处理通过将多个DML语句分组到一个操作中来提高性能，从而减少数据库往返。

读自己写的一致性

由于查询始终针对数据库运行（除非命中了二级查询缓存），因此我们需要确保在查询开始运行之前，所有未决的更改都已同步。

因此，JPA和Hibernate都定义了“ 查询前刷新”同步策略。

从JPA到Hibernate冲洗策略

JPA FlushModeType	休眠刷新模式	Hibernate实现细节
汽车	汽车	有时会在查询执行前刷新会话。
承诺	承诺	会话仅在事务提交之前刷新。
	总是	在执行查询之前， 始终刷新会话。
	手册	该会话只能 手动刷新 。
	决不	不推荐使用。 请改用MANUAL。 这是手动刷新的原始名称，但它误导用户以为Session永远不会被刷新。

当前冲洗范围

持久性上下文定义了默认的刷新模式，可以在创建Hibernate Session时覆盖它。 查询还可以采用刷新策略，因此会否决当前的持久性上下文刷新模式。

范围	冬眠	JPA
持久性上下文	届会	实体管理器
询问	询问 标准	询问 类型查询

敬请关注

在我的下一篇文章中，您将发现Hibernate FlushMode.AUTO破坏了SQL查询的数据一致性，并且您将看到如何克服这一缺点。

翻译自: https://www.javacodegeeks.com/2014/08/a-beginners-guide-to-jpahibernate-flush-strategies.html