什么時候不使用EntityManager.flush（）？

Question

為了同步和檢索DB生成的ID，我覺得強迫在幾個地方調用EntityManager.flush() 。

除了性能影響，有沒有理由不調用flush() ？

換句話說，如果我的（DAO，...）方法的調用者是否/不是flush() ，是否有任何可觀察到的差異？

我的場景是在支持JPA開發人員的框架環境中。 我會提供一些功能，這些功能可能需要或不需要在調用層次結構深處的某個地方進行flush() 。 這些函數的用戶是否必須知道是否/何時發生刷新，或者它是否是私有實現細節而對調用者沒有明顯影響？

Answer 1

對flush()調用將持久化上下文與數據庫同步。 這主要是必需的 - 如果需要查詢命中（通過JPQL等）。

稍后在調用堆棧到數據庫，並且如果持久性上下文包含其狀態可能受查詢結果影響的任何對象的臟值，則需要同步這些對象。 事實上，JPA查詢的默認FlushModeType是AUTO

在事務中執行查詢時，如果在Query或TypedQuery對象上設置了FlushModeType.AUTO，或者持久性上下文的刷新模式設置為AUTO（默認值）並且尚未為查詢指定刷新模式設置或TypedQuery對象，持久性提供程序負責確保對持久性上下文中可能影響查詢結果的所有實體的狀態的所有更新對於查詢的處理是可見的。 持久性提供程序實現可以通過將這些實體刷新到數據庫或通過某些其他方式來實現。

因此，只要您通過其狀態查詢對象而不是JPA查詢並且這些查詢的結果不依賴於臟狀態，那么性能調用刷新是不好的，因為它涉及重復的臟狀態檢查而不是僅僅在提交時。

@Adams提到了他在使用OpenJPA的經歷，其中flush打破了一些東西，所以我猜這里有不同的實現問題。

Answer 2

性能幾乎總結了“不”調用flush的大部分原因。 Flush是一種強制所有更改語句立即被推送到數據庫的方法，而不是累積並作為更大的批處理發送。 它可能很有用，因為某些事務可能非常大並且需要清除以釋放內存，以及強制某個訂單使您的更新進入數據庫。

除了性能和提供程序特定問題之外，不調用flush的唯一其他原因是特定於應用程序，例如某些更改可能違反數據庫約束並且稍后需要進一步修改。