為每個Web應用程序（上下文）保存一個存儲庫是更好還是通過JNDI或類似技術共享一個公共實例更好？

Question

在我們公司內部，這是一種為原始存儲在數據庫中的數據創建存儲庫的標准，例如https://thinkinginobjects.com/2012/08/26/dont-use-dao-use-repository/中所述 。

我們的Web基礎結構由Tomcat 7中的一些獨立的Web應用程序組成，這些應用程序用於打印，產品描述，產品訂單（這在數據庫中不存在！），類別描述等。它們都基於Servlet 2 API構建。

因此，存儲庫的每個實例/實現都持有一種特殊的數據，該數據由可序列化的類表示，並且此可序列化的類的實例由定期執行的數據庫查詢來設置/填充（對於每個結果行，都將調用字段的setter；讓我想起了CMP的面向領域的實體bean）。 在servlet的初始化序列上初始化存儲庫（因此，每個servlet都保留自己的實例集）。 每個上下文都有自己的與Oracle數據庫的連接（由部署時的資源描述文件設置）。 所有數據都是只讀的，我們永遠不需要寫回數據庫。

因為我們需要在多個Web應用程序（上下文）中使用其中一些數據類型，而在具有相同數據類型的相同Web上下文存儲庫中甚至需要多個（甚至多個）Servlet，則需要多次實例化-例如，四次，兩次在同一實例中應用。

最后，一些數據翻了一番，我不確定這是否應有的聰明和有效。 應該可以與多個應用程序（JNDI？）共享同一存儲庫對象，但至少必須可以在同一應用程序上下文中為多個servlet共享它。 盡管我對使用“自行構建”存儲庫而不是經過良好測試的開放開發緩存（ehcache，jcs等）的想法感到惱火，因為其中某些緩存還提供了分布式緩存的選項（因此它也應該在同一個容器中工作）。 如果搜索到某些條目，則搜索算法將遍歷存儲庫中的所有條目（上面的鏈接）。 對於每種搜索模式，都有專門的功能，可以使用“實體Bean”從業務邏輯類中直接調用這些功能； 沒有規范對象或接口。

最后，應用服務器整體上表現不佳，並且使用了大量的RAM（至少用於大約10000個DB條目）。 在我看來，這很可能與使用可序列化的XSD到JAXB生成的類有關。

此外，每次部署應用程序進行測試時，您都必須等待至少兩分鍾，直到數據庫的所有條目都已加載到存儲庫中為止-實時部署時，在上下文/ servlet啟動時，服務階段已經很容易識別。 我傾向於認為所有這些都與我上面描述的解決方案密切相關。

因為我沒有在該領域的任何經驗，而且我是公司的新人，所以我不想太過分。

也許您可以幫助我評估構想，以獲得更好的設置：

是否為了提高性能和內存而將所有存儲庫統一為一個“存儲庫servlet”並通過HTTP從那里請求對象（不要這樣，盡管看起來非常模塊化/分布式系統友好），還是應該嘗試使用JNDI？ （以前從未這樣做過）並連接到類似於JDBC數據庫的存儲庫嗎？

至少為整個Tomcat只使用一個連接池（並從Web應用程序部署描述符中引用該連接池）會更明智，更快速，更高效嗎？ 還是可能減慢連接速度或將其限制在任何其他方面？ 有人告訴我緩存系統（ehcache）不能很好地工作（至少在自寫解決方案的性能上不行-但是：我真不敢相信）。 我想在所有Web應用程序中使用由分布式（在所有上下文中）緩存支持的存儲庫，不僅應顯着減少內存占用，而且不應顯着降低速度。 -我相信它會更快，啟動時間更短，因此不需要經常重新部署它。

非常感謝您的每一個提示或提示以及您的想法。 根據實際經驗對我的想法進行同行評審會很棒。

因此，非常感謝您！

Answer 1

為每個Web應用程序（上下文）保存一個存儲庫是更好還是通過JDNI或類似技術共享一個公共實例更好？

除非有人向我證明，否則我將無法以標准方式（即Servlet Sepc或Java EE規范其余部分中定義的方式）進行操作。

有一些技術方法可能取決於特定的應用程序服務器實現，但這在通用意義上不能“更好”。

如果您有兩個處理相同數據的應用程序，我想知道對應用程序進行分區是否有用。 也許對某種數據進行操作的所有功能都必須在同一應用程序中？

在我們公司內部，這是一種為原始存儲在數據庫中的數據創建存儲庫的標准，例如https://thinkinginobjects.com/2012/08/26/dont-use-dao-use-repository/中所述 。

我在書架上抬頭看着埃文斯。 博客文章很奇怪。 存儲庫和DAO基本上是同一件事，它為對象或對象樹提供CRUD操作（Evans僅表示聚合根）。

在servlet的初始化序列上初始化存儲庫（因此，每個servlet都保留自己的實例集）。 每個上下文都有自己的與Oracle數據庫的連接（由部署時的資源描述文件設置）。 [...]最終，應用服務器整體上表現不佳，並且使用了大量的RAM

當某件事表現不佳時，最好進行性能分析，例如，如果您使用的是Linux，則使用YourKit或perf和FlameGraphs。 如果您的應用程序需要大量RAM，請使用Eclipse MAT分析堆。 在沒有看到任何代碼行的情況下，沒有人可以給您推薦或暗示最佳實踐。

一般的答案將包括有關Oracle DB，JDBC，Java集合以及並發編程，網絡和操作系統的性能調優的所有內容。

有人告訴我緩存系統（ehcache）不能很好地工作（至少在自寫解決方案的性能上不行-但是：我不敢相信）

我可以。 EHCache比簡單的HashMap慢10到20倍。 請參閱： 緩存基准 。 當您完成一個完整的預加載並且沒有任何突變時，您只需要一個圖。

我想在所有Web應用程序中使用由分布式（在所有上下文中）緩存支持的存儲庫，不僅應顯着減少內存占用，而且不應顯着降低速度

分布式緩存需要遍歷網絡並增加序列化/反序列化開銷。 這可能是另一個慢30倍的因素。 分布式緩存何時更新？

非常感謝您的每一個提示或提示以及您的想法。

包起來：

1. 進行正常的軟件工程作業，進行性能分析和分析，並在正確的位置進行調整
2. 在關於堆棧溢出的一個主題上提出特定問題，並共享您的代碼和性能數據。 一次提出關於一件事的問題，並閱讀https://stackoverflow.com/help/on-topic
3. 您可能還會得出結論，沒有什么可調整的。 有一些應用程序需要一天的時間才能從持久性數據中構建內存數據結構。 也許只是很多數據？ 如果您不喜歡停機，請使用綠色藍色部署。 還使用較小的數據集進行開發和測試