介紹

既然我已經(jīng)描述了JPA和Hibernate刷新策略的基礎(chǔ)知識 ，我就可以繼續(xù)闡明Hibernate的AUTO刷新模式的令人驚訝的行為。

并非所有查詢都會觸發(fā)會話刷新

許多人會認為Hibernate 總是在執(zhí)行任何查詢之前先刷新Session。 雖然這可能是一種更直觀的方法，并且可能更接近JPA的AUTO FlushModeType ，但是Hibernate嘗試對其進行優(yōu)化。 如果當(dāng)前執(zhí)行的查詢不會命中未決的SQL INSERT / UPDATE / DELETE語句，則不嚴格要求刷新。

如參考文檔中所述，AUTO刷新策略有時可能在執(zhí)行查詢之前同步當(dāng)前持久性上下文。 如果框架作者選擇將其命名為FlushMode.SOMETIMES，那將更加直觀。

JPQL / HQL和SQL

與許多其他ORM解決方案一樣，Hibernate提供了一種非?；赟QL-92語法的有限實體查詢語言（ JPQL / HQL ）。

當(dāng)前數(shù)據(jù)庫方言將實體查詢語言轉(zhuǎn)換為SQL，因此它必須在不同的數(shù)據(jù)庫產(chǎn)品中提供相同的功能。 由于大多數(shù)數(shù)據(jù)庫系統(tǒng)都是SQL-92投訴，因此實體查詢語言是最常見的數(shù)據(jù)庫查詢語法的抽象。

雖然您可以在許多用例（選擇實體，甚至是投影）中使用實體查詢語言，但有時其有限功能與高級查詢請求不匹配。 每當(dāng)我們想要利用某些特定的查詢技術(shù)時，例如：

• 視窗功能
• 數(shù)據(jù)透視表
• 常用表表達式

我們別無選擇，只能運行本機SQL查詢。

Hibernate是一個持久性框架。 Hibernate從未打算取代SQL。 如果某些查詢在本機查詢中可以更好地表達，那么在數(shù)據(jù)庫可移植性上犧牲應(yīng)用程序性能是不值得的。

自動沖洗和HQL / JPQL

首先，我們將測試將要執(zhí)行HQL查詢時AUTO刷新模式的行為。 為此，我們定義了以下不相關(guān)的實體：

該測試將執(zhí)行以下操作：

• 一個人將被堅持。
• 選擇用戶不應(yīng)觸發(fā)刷新。
• 查詢?nèi)藛T時，AUTO刷新應(yīng)觸發(fā)實體狀態(tài)轉(zhuǎn)換同步（應(yīng)在執(zhí)行選擇查詢之前執(zhí)行人員INSERT）。

Product product = new Product(); session.persist(product); assertEquals(0L, session.createQuery("select count(id) from User").uniqueResult()); assertEquals(product.getId(), session.createQuery("select p.id from Product p").uniqueResult());

提供以下SQL輸出：

[main]: o.h.e.i.AbstractSaveEventListener - Generated identifier: f76f61e2-f3e3-4ea4-8f44-82e9804ceed0, using strategy: org.hibernate.id.UUIDGenerator Query:{[select count(user0_.id) as col_0_0_ from user user0_][]} Query:{[insert into product (color, id) values (?, ?)][12,f76f61e2-f3e3-4ea4-8f44-82e9804ceed0]} Query:{[select product0_.id as col_0_0_ from product product0_][]}

如您所見，用戶選擇尚未觸發(fā)會話刷新。 這是因為Hibernate會根據(jù)掛起的表語句檢查當(dāng)前查詢空間。 如果當(dāng)前正在執(zhí)行的查詢與未刷新的表語句不重疊，則可以安全地忽略刷新。

HQL甚至可以在以下情況下檢測到產(chǎn)品沖洗：

• 子選擇 session.persist(product); assertEquals(0L, session.createQuery("select count(*) " +"from User u " +"where u.favoriteColor in (select distinct(p.color) from Product p)").uniqueResult());

  導(dǎo)致正確的沖洗調(diào)用：

  Query:{[insert into product (color, id) values (?, ?)][Blue,2d9d1b4f-eaee-45f1-a480-120eb66da9e8]} Query:{[select count(*) as col_0_0_ from user user0_ where user0_.favoriteColor in (select distinct product1_.color from product product1_)][]}
• 或theta風(fēng)格的聯(lián)接 session.persist(product); assertEquals(0L, session.createQuery("select count(*) " +"from User u, Product p " +"where u.favoriteColor = p.color").uniqueResult());

  觸發(fā)預(yù)期的沖洗：

  Query:{[insert into product (color, id) values (?, ?)][Blue,4af0b843-da3f-4b38-aa42-1e590db186a9]} Query:{[select count(*) as col_0_0_ from user user0_ cross join product product1_ where user0_.favoriteColor=product1_.color][]}

它起作用的原因是因為實體查詢已被解析并轉(zhuǎn)換為SQL查詢。 Hibernate無法引用不存在的表，因此它始終知道HQL / JPQL查詢將命中的數(shù)據(jù)庫表。

因此，Hibernate僅知道我們在HQL查詢中顯式引用的那些表。 如果當(dāng)前待處理的DML語句暗示數(shù)據(jù)庫觸發(fā)器或數(shù)據(jù)庫級級聯(lián)，則Hibernate將不會意識到這些。 因此，即使對于HQL，“自動”刷新模式也可能導(dǎo)致一致性問題。

自動刷新和本機SQL查詢

當(dāng)涉及本地SQL查詢時，事情變得越來越復(fù)雜。 Hibernate無法解析SQL查詢，因為它僅支持有限的數(shù)據(jù)庫查詢語法。 許多數(shù)據(jù)庫系統(tǒng)提供了超越Hibernate Entity Query功能的專有功能。

使用本機SQL查詢查詢Person表不會觸發(fā)刷新，從而導(dǎo)致不一致問題：

Product product = new Product(); session.persist(product); assertNull(session.createSQLQuery("select id from product").uniqueResult());DEBUG [main]: o.h.e.i.AbstractSaveEventListener - Generated identifier: 718b84d8-9270-48f3-86ff-0b8da7f9af7c, using strategy: org.hibernate.id.UUIDGenerator Query:{[select id from product][]} Query:{[insert into product (color, id) values (?, ?)][12,718b84d8-9270-48f3-86ff-0b8da7f9af7c]}

新保留的產(chǎn)品僅在事務(wù)提交期間插入，因為本機SQL查詢未觸發(fā)刷新。 這是主要的一致性問題，許多開發(fā)人員很難調(diào)試甚至無法預(yù)見。 這是始終檢查自動生成的SQL語句的另一個原因。

即使對于命名的本機查詢，也會觀察到相同的行為：

@NamedNativeQueries(@NamedNativeQuery(name = "product_ids", query = "select id from product") ) assertNull(session.getNamedQuery("product_ids").uniqueResult());

因此，即使SQL查詢已預(yù)先加載，Hibernate也不會提取關(guān)聯(lián)的查詢空間以使其與未決的DML語句匹配。

否決當(dāng)前的沖洗策略

即使當(dāng)前會話定義了默認的刷新策略，您也可以始終在查詢基礎(chǔ)上覆蓋它。

查詢刷新模式

ALWAYS模式將在執(zhí)行任何查詢（HQL或SQL）之前刷新持久性上下文。 這次，Hibernate沒有應(yīng)用任何優(yōu)化，所有待處理的實體狀態(tài)轉(zhuǎn)換都將與當(dāng)前數(shù)據(jù)庫事務(wù)同步。

assertEquals(product.getId(), session.createSQLQuery("select id from product").setFlushMode(FlushMode.ALWAYS).uniqueResult());

指示Hibernate應(yīng)該同步哪些表

您還可以在當(dāng)前正在執(zhí)行的SQL查詢上添加同步規(guī)則。 然后，Hibernate將知道在執(zhí)行查詢之前需要同步哪些數(shù)據(jù)庫表。 這對于二級緩存也很有用。

assertEquals(product.getId(), session.createSQLQuery("select id from product").addSynchronizedEntityClass(Product.class).uniqueResult());

結(jié)論

自動刷新模式非常棘手，并且在查詢基礎(chǔ)上解決一致性問題是維護人員的噩夢。 如果決定添加數(shù)據(jù)庫觸發(fā)器，則必須檢查所有Hibernate查詢，以確保它們最終不會針對過時的數(shù)據(jù)運行。

我的建議是使用ALWAYS刷新模式，即使Hibernate作者警告我們：

這種策略幾乎總是不必要且效率低下的。

不一致是一些偶爾過早沖洗的問題。 當(dāng)混合DML操作和查詢可能會導(dǎo)致不必要的刷新時，這種情況很難緩解。 在會話事務(wù)期間，最好在事務(wù)開始時（沒有待處理的實體狀態(tài)轉(zhuǎn)換要同步時）和事務(wù)結(jié)束時（無論如何將刷新當(dāng)前持久性上下文）執(zhí)行查詢。

應(yīng)將實體狀態(tài)轉(zhuǎn)換操作推向事務(wù)的結(jié)尾，以嘗試避免將它們與查詢操作交錯（因此防止過早的刷新觸發(fā)器）。

翻譯自: https://www.javacodegeeks.com/2014/08/the-dark-side-of-hibernate-auto-flush.html

總結(jié)

以上是生活随笔為你收集整理的休眠自动冲洗的黑暗面的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。