Лучше ли хранить хранилище для каждого веб-приложения (контекста) или лучше использовать общий экземпляр JNDI или аналогичный метод

Question

в нашей компании, это своего рода стандарт для создания репозиториев для данных, которые изначально хранятся в как описано, например, в https://thinkinginobjects.com/2012/08/26/dont-use-dao-use-repository/.

Наша веб-инфраструктура состоит из нескольких независимых веб-приложений в Tomcat 7 для печати, описания продукта, заказа продукта (это не сохраняется в базе данных!), Описание категории и т. Д. Все они основаны на API Servlet 2.

Таким образом, каждый экземпляр/реализация хранилища хранит специализированный вид данных, представляемых сериализуемыми классами, и экземпляры этих сериализуемых классов настраиваются/заполняются периодически выполняемым запросом базы данных (для каждого результата создаются сеттеры полей , напоминает мне о объектно-ориентированных объектных компонентах с CMP). Репозитории инициализируются последовательностями инициализации сервлетов (поэтому каждый сервлет сохраняет собственный набор экземпляров). Каждый контекст имеет собственное соединение с базой данных Oracle (настроено файлом описания ресурсов при развертывании). Все данные доступны только для чтения, нам больше не нужно писать обратно в базу данных.

Поскольку нам нужны некоторые из этих типов данных для более чем одного веб-приложения (контекста), а некоторые даже для более одного сервлета в пределах одного и того же хранилища веб-контекста с идентичным типом данных создаются несколько раз - например. четыре раза, дважды в одном приложении.

В конце некоторые данные удвоены, и я не уверен, насколько это так умно и эффективно, как должно быть. Должна быть доступна возможность совместного использования одного и того же объекта репозитория более чем с одним приложением (JNDI?), Но, по крайней мере, должно быть возможно предоставить его для нескольких сервлетов в одном и том же контексте приложения. Несмотря на то, что я раздражен идеей использовать репозиторий «self build», а не что-то вроде хорошо протестированного открытого кэша (ehcache, jcs, ...), потому что некоторые из этих кэшей также предоставляют параметры для распределенных кешей (так он также должен работать в одном контейнере). Если поиск выполняется в определенных записях, алгоритм поиска выполняет итерацию по всем позициям в ссылке репозитория (см. Выше). Для каждого шаблона поиска существуют специализированные функции, которые непосредственно вызываются из классов бизнес-логики с использованием «entity beans»; нет спецификационного объекта или интерфейса.

В конце концов, сервер приложений в целом не работает так хорошо, и он использует много ОЗУ (по крайней мере, для приблизительно 10000 записей в БД); это, на мой взгляд, скорее всего, связано с использованием сериализуемых классов XSD-to-JAXB.

Кроме того, каждый раз, когда приложение развертывается для тестирования, вы должны ждать не менее двух минут, пока все записи базы данных не будут загружены в репозитории - при развертывании в режиме реального времени есть хорошо узнаваемая фаза обслуживания в контексте/сервлет запускать. Я склонен думать, что все это тесно связано с решениями, описанными выше.

Поскольку у меня нет опыта в этой области, и я новичок в компании, я не хочу быть навязчивым.

Может быть, вы можете мне помочь оценить идеи для лучшей установки:

это для производительности и памяти лучше объединить все репозитории в одном «хранилище сервлетов» и объектов запроса оттуда через HTTP (не так думаю, хотя он кажется довольно модульным/распределенным в системе) или я должен попытаться пойти с JNDI (никогда раньше этого не делал) и подключиться к репозиторию, подобному базе данных JDBC?

Не было бы еще более разумным, быстрым и эффективным, по крайней мере, использовать только один пул соединений для всего Tomcat (и ссылаться на этот пул соединений из дескриптора развертывания веб-приложений)? Или это может замедлить соединение или ограничить его в любом другом аспекте? Мне сказали, что система кеша (ehcache) не работает хорошо (по крайней мере, не с выполнением собственного письменного решения - хотя: я не могу в это поверить). Я полагаю, что использование репозиториев, поддерживаемых распределенным (как во всех контекстах) кешем, используемым во всех веб-приложениях, должно не только значительно уменьшить объем памяти, но и не будет значительно медленнее. - Я считаю, что это будет быстрее и у них будет более короткое время запуска, соответственно, не нужно будет часто перераспределять его.

Я очень благодарен за каждый совет или подсказку и ваши мысли. Было бы замечательно получить экспертную оценку моих идей на основе практического опыта.

Так что спасибо вам большое!

Answer 1

ли лучше держать хранилище для каждого веб-приложения (контекст), или лучше использовать общий экземпляр по JDNI или подобную технику

Если кто-то не докажет мне, иначе я бы сказал, это не способ сделать это стандартным образом, как это определено в Servlet Sepc или в остальной части канона спецификации Java EE.

Существуют технические способы, которые, вероятно, зависят от конкретной реализации сервера приложений, но это не может быть «лучшим» в своем универсальном смысле.

Если у вас есть два приложения, которые работают с одними и теми же данными, интересно, полезно ли разбиение приложений. Может быть, все функции, работающие на каких-то данных, должны находиться в одном приложении?

В нашей компании это стандарт для создания репозиториев для данных, которые изначально хранятся в базе данных, как описано, например, в https://thinkinginobjects.com/2012/08/26/dont-use-dao-use-repository/.

Я искал Эванс в нашей книжной полке. Сообщение в блоге довольно странно. Репозиторий и DAO в основном одно и то же, он обеспечивает операции CRUD для объекта или для дерева объектов (Эванс говорит только об общих корнях).

Репозитории инициализируются последовательностями инициализации сервлетов (поэтому каждый сервлет хранит собственный набор экземпляров). Каждый контекст имеет собственное соединение с базой данных Oracle (настроено файлом описания ресурсов при развертывании). [...] В конце концов, сервер приложений в целом не выполняет, что хорошо, и он использует ад много RAM

Когда что-то выполняет плохо его лучше, чтобы сделать профилирование, например, с YourKit или с perf и FlameGraphs, если вы находитесь в Linux. Если вашим приложениям требуется много оперативной памяти, проанализируйте кучу, например. с Eclipse MAT. Никто не может дать вам рекомендации или намек на лучшую практику, не видя какой-либо строки кода.

Общий ответ включал бы вопросы о настройке производительности для Oracle DB, JDBC, сборников Java и параллельного программирования, сетевых и операционных систем.

мне сказали, что система кэширования (EHCache) так хорошо не работает (по крайней мере, не с выполнением самостоятельной письменное решение - хотя: Я не могу поверить, что)

I Можно. EHCache находится в 10-20 раз медленнее, чем простая HashMap. См .: cache benchmarks. Вам нужна только карта, когда вы выполняете полную предварительную загрузку и не имеете никаких мутаций.

Я представляю себе использование хранилищ, подкрепленных распределенной (как во всех контекстах) кэш-памяти, используемой во всех веб-приложений должны не только уменьшить объем памяти значительно, но не должна быть значительно медленнее

Распределенные кэши нужны переходить через сеть и добавлять служебные данные для сериализации/десериализации. Это, вероятно, еще один фактор 30 медленнее. Когда обновляется распределенный кеш?

Я очень благодарен за каждый отзыв или подсказку и ваши мысли.

Подведение итогов:

1. ли нормальный разработки программного обеспечения домашние задания, делать профилирование и анализ и тратить усилия на настройки в нужных местах
2. Задавайте конкретные вопросы по одной теме на StackOverflow и поделиться своими кода и данных о производительности. Задайте вопрос об одной вещи одновременно и читайте https://stackoverflow.com/help/on-topic
3. Вы также можете прийти к выводу, что настроить мелодию не на что. Есть приложения, которые нуждаются в день для создания структуры данных в памяти из постоянных данных. Может быть, это просто много данных? Если вам не нравится время простоя, используйте зеленое синее развертывание. Также используйте меньшие наборы данных для разработки и тестирования