在軟刪除的情況下休眠第二級緩存

Question

與主數據模塊的插入/更新/刪除操作相比，讀操作非常高。到現在爲止，我們正在使用JDBC進行讀取，寫入和更新操作。在刪除操作中，我們正在進行軟刪除（將IS_DELETED列標記爲'Y'）。所有的寫/更新方法都是同步的，以處理concurreny。我們正在使用oracle，並且沒有計劃支持多個數據庫。

現在，我們正在計劃緩存數據，並且我們還計劃進行羣集。

我們最簡單的選擇是更改插入/更新/刪除方法並使用類似ehcache的東西來按照我們的要求管理緩存，並通過使用表中的版本列來處理羣集環境中的併發性並刪除同步關鍵字。

其他選項，我周圍的人建議（事實上要求我做）是移動到休眠（我不太瞭解休眠），這將自動處理緩存和併發。

這裏是我的疑惑：

1）是否值得給予我們大約有200臺對依法治主數據更改的完整DAO代碼？

2）在這種情況下，休眠第二級緩存的幫助，因爲我們需要再次過濾緩存的數據以放棄刪除的行，或者存在一種hibernate（或任何其他方式）的機制，通過它我們可以在數據庫中執行更新操作但在緩存的數據中刪除操作？ 3）我們已經將數據傳輸對象暴露給具有存儲在單獨的PK對象中的主表的所有字段的其他模塊（具有主鍵字段在單獨的對象中），並且我們沒有參考DO在它（複合DO不在那裏）。鑑於，我們不能改變公開的方法和DO結構 - 那麼我們必須再次在我們的DO中打包Hibernate緩存的實體數據嗎？或者我們可以重用舊的DO結構作爲hibernate實體（因爲我的cognindg PK列應該直接在hibenate實體中，而不是在某個組合對象中）。我提到了複合DO，因爲我們也有依賴的下拉需求，如果我們在第一個地方有複合DO，那麼它可以用於hibernate延遲加載子對象。反對的意思是提供使用緩存數據和刪除舊方法的新方法。其他模塊會根據緩存的需要慢慢遷移，但是我們將維護問題，因爲我們必須在db更改的情況下維護這兩種方法。另外，還有1個和2個疑問。

我相信在這個階段hibernate並不適合我們，我必須說服周圍的人，但我想知道您對移動到休眠而非二級自動管理的長期優勢的看法緩存，併發處理（我們可以通過在普通位置更改小代碼來完成）和db獨立性（我們不感興趣）更改完整代碼的代價。

Answer 1

如果您打算遷移到休眠狀態，你應該在考慮 1）你需要映射所有的結構POJO的（如果你還沒有的話） 2）重寫所有DAO的使用Hibernate（記住裸，休眠QL /條件API有一定的限制 3）準備打懶惰的初始化問題，等等...... 個人認爲我不認爲它值得遷移到休眠與工作模式，除非它是極其痛苦的維持當前模型

關於你的2個和3個問題 2）二級高速緩存只容納加載的實例，由主鍵訪問。即如果你說hibernateSession。load（User，10） - 它將使用id = 10在二級緩存中查找用戶對象。如果我明白瞭解情況並非如此。大多數情況下，您想要使用更復雜的查詢加載數據 - 在這種情況下，您需要使用StandarQueryCache，它將查詢字符串映射到加載的ID列表，然後將從第二級緩存中檢索。但是，如果你有很多相似度很低的查詢 - StandartQueryCache和二級緩存將是完全無用的（看看http://darren.oldag.net/2008/11/hibernate-query-cache-dirty-little_04.html） 3）你可以使用組件等，但我不知道你的DTO結構。

希望幫助