介紹

在我之前的文章中，我介紹了實體狀態轉換 對象關系映射范例。

當刷新當前持久性上下文時，所有管理實體狀態轉換都將轉換為關聯的數據庫語句。 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

總結

以上是生活随笔為你收集整理的JPA /休眠刷新策略初学者指南的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。