hibernate臟數據

介紹

持久性上下文使實體狀態轉換入隊 ，該實體狀態轉換在刷新后轉換為數據庫語句。 對于托管實體，Hibernate可以代表我們自動檢測傳入的更改并安排SQL UPDATE。 這種機制稱為自動臟檢查 。

默認的臟檢查策略

默認情況下，Hibernate檢查所有托管實體屬性。 每次加載實體時，Hibernate都會復制所有實體屬性值。 在刷新時，每個受管實體屬性都會與加載時快照值匹配：

因此，各個臟檢查的數量由以下公式給出：

哪里

n =受管理實體的數量
p =給定實體的實體數

即使單個實體的僅一個屬性發生了變化，Hibernate仍將檢查所有托管實體。 對于大量的受管實體，默認的臟檢查機制可能會占用大量CPU和內存。 由于初始實體快照是單獨保存的，因此持久性上下文所需的內存是所有受管實體通常占用的內存的兩倍。

字節碼檢測

一種更有效的方法是在值更改時標記臟屬性。 與原始的深度比較策略類似，優良作法是將域模型結構與更改檢測邏輯分離。 自動實體更改檢測機制是一個跨領域的問題 ，可以在構建時或運行時進行編織。

實體類可以附加實現自動臟檢查機制的字節碼級指令。

編織方式

字節碼增強可以發生在：

• 構建時間編譯Hibernate實體之后，構建工具（例如ANT ， Maven ）將在每個已編譯實體類中插入字節碼級別的指令。 由于類是在構建時增強的，因此此過程不會產生額外的運行時損失。 可以針對增強的類版本進行測試，以便在構建項目之前驗證實際的生產代碼。
• 運行時可以使用以下方法完成運行時編織：
  • Java代理，在實體類加載時進行字節碼增強

邁向默認字節碼增強臟檢查

Hibernate 3一直通過ANT目標提供字節碼檢測，但是它從未成為主流，大多數Hibernate項目目前仍在使用默認的深度比較方法。

雖然其他JPA提供程序（例如OpenJPA ， DataNucleus ）一直在支持字節碼增強方法，但是Hibernate才剛剛開始朝這個方向發展，提供了更好的構建時選項，甚至提供了自定義的臟檢查回調 。

在我的下一篇文章中，我將向您展示如何使用自己的應用程序特定策略自定義臟檢查機制。

翻譯自: https://www.javacodegeeks.com/2014/08/the-anatomy-of-hibernate-dirty-checking.html

hibernate臟數據

總結

以上是生活随笔為你收集整理的hibernate脏数据_Hibernate脏检查的剖析的全部內容，希望文章能夠幫你解決所遇到的問題。

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