ORM查詢？或更新的數據庫表信息應更新到Hibernete Web應用程序？

Question

問題說明： 示例：我有名爲「STUDENT」的表名，它有10行，並且認爲其中一行的名稱爲「Jack」。因此，當我的服務器啓動並運行時，我將數據庫數據庫製作成緩存內存，以便我的應用程序具有「插口」的值，並且我將其用於整個應用程序。

現在外部來源更改了我的「學生」表並將名稱「傑克」更改爲「帕布傑克」。我想更新信息asap進入我的應用程序與刷新/刷新到我的應用程序..我不想運行一些不斷的線程來監視和更新我的應用程序。我想要的只是hibernate的一部分或任何可行的解決方案來實現這一目標？

..

Answer 1

你描述的是是否拉或推更新的經典案例。

拉

這種方法依賴於使用一些後臺線程或任務系統定期輪詢資源，並請求所需的信息的應用程序。它是應用程序執行此任務的責任。

爲了在與Hibernate的緩存實現結合使用拉機制，這將意味着你會希望你的Hibernate查詢結果存儲在L2緩存實現，如ehcache的。

您的ehcache將指定存儲容量和過期詳細信息，並且您只需在每個需要的位置查詢學生數據。首先會查詢L2高速緩存，它位於應用程序服務器端，如果L2高速緩存已過期，則只會查詢數據庫。

缺點是您需要爲L2緩存指定一個合理的生存時間設置，以便在更新行之後緩存在合理範圍內通過查詢進行更新。根據更改和使用的頻率，也許5分鐘的窗口就足夠了。

使用L2高速緩存可防止需要無用的後臺輪詢線程，並允許您在由Hibernate實現支持的Hibernate框架內指定合理的輪詢時間。

推

這種方法依賴於其中發生變化時能夠通知事情發生了轉變有關各方，並允許當事人執行一些動作的點。

爲了使用推送機制，您的應用程序需要公開一種方式來告訴發生的變化，最好是實際發生的變化。然後，當你的外部來源修改有問題的表格時，該操作需要提出事件並通知相關方。

構建這種方法的一種方法是使用JMS代理並讓外部源向隊列提交JMS消息，讓應用程序訂閱JMS隊列以在發送消息時讀取消息。

另一個解決方案是將外部源與應用程序緊密操縱數據的地方連接起來，這樣外部源不僅可以處理有問題的數據，還可以嚮應用程序發送JSON請求，從而允許它立即更新其內部緩存。

結論

使用推情況可能需要引進更多的中間件組件，你應該要能夠有效地分離外部源側&您的應用程序。但它確實帶來了額外的好處，即數據庫和應用程序緩存之間的最終一致性應該以相對實時的方式發生。此解決方案在啓動後還無需爲這些行查詢數據庫。

使用拉情況並不需要任何比你可能已經在使用你的應用程序更多，也許比使用支持L2緩存提供者，而不是一些土生土長的解決方案等。但是，數據庫與應用程序緩存之間的最終一致性完全取決於該實體緩存的TTL配置。但請注意，一旦您的TTL過期，此解決方案將繼續查詢數據庫以刷新緩存。