2
當I java.persistence.EntityManger.find（）是一個@Entity時，EntityManager會檢查事務是否存在與其關聯的持久性上下文的現有實例。如果如果搜索的是存在於上下文中的實體中的一個存在，那麼如何對JPA實體進行實際跟蹤
- ，那就是如果被搜索的實體是什麼返回EntityManager.find
- 的主叫方不存在背景，然後從EntityManager的數據源得到它，並把它在那裏，然後就是什麼返回到EntityManager.Find
的呼叫者，而如果交易不包含經理的相關持久化上下文的現有實例，那麼管理者創建一個，將其與事務相關聯，在數據源中找到該實體，並將其添加到該上下文中進行管理，然後將該實體返回給find的調用者。
- >結果是相同的，調用者現在有一個存在於持久化上下文中的託管實體。 （重要的是：持久性上下文被附加到事務中，所以如果事務在客戶端獲得了「被管理」實體的地方結束，那麼持久化上下文不再是實體，並且該實體被「分離」了不再管理）。
現在，當我在@entity實例中使用setter或其他內部狀態更改方法進行狀態更改時，會跟蹤這些更改，因爲我的實體是持久性上下文的一部分，當事務最終提交時它將被刷新到數據源。我的問題是如何跟蹤狀態變化並通過什麼進行跟蹤？如果我通過某個中間對象進行更改，則該中間對象可以相應地更新持久化上下文，但我不是（或者我？）。我直接使用我的@entity註釋對象進行更改。那麼如何跟蹤這些變化。
也許有些事件正在被聆聽？聽什麼？我正在閱讀關於這個主題的書籍和文章，但是我不能把這一點搞砸。
這就是所謂的「髒檢查」。現在，將新學習的關鍵字與「jpa」或「hibernate」或任何您正用作附加關鍵字的impl結合使用。它有沒有產生有益的答案？一般來說，它歸結爲代理模式。 – BalusC
謝謝。完善。 – naftalimich
可能的重複：http://stackoverflow.com/questions/8507922/jpa-dirty-checking – BalusC