Получить все необходимые данные при запуске - PullRequest
2 голосов
/ 09 февраля 2011


В Java Web Application я хотел бы знать, является ли это правильным (или «стандартным»?) Способом, которым все необходимые данные, такие как данные конфигурации, данные сообщений, данные обслуживания кода, данные опций выпадающего менюи т. д. (при условии, что все данные не будут часто обновляться) загружаются как «статические» переменные из базы данных при запуске сервера.

Или это более предпочтительный способ получения данных путем запроса дБ для каждого запроса?

Спасибо за все ваши советы здесь.

Ответы [ 2 ]

2 голосов
/ 09 февраля 2011

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

Это хорошая идея, поскольку она сохраняет попадания в БД и ускоряет поиск. Многие параметры среды и другие данные также могут быть извлечены один раз и сохранены в неизменяемом хэш-файле для любого будущего запроса.

В обычном веб-приложении у вас обычно не так много конфигурационных данных / опционных объектов, которые могут потреблять много памяти и вызывать OOM. Но, если у вас есть таблица с сотнями тысяч конфигурационных данных, лучше предположить, что вы извлекаете объекты по запросу. И если вы do хотите сохранить его в памяти, подумайте о том, чтобы поместить его в какое-то хранилище значений ключей, например MemcacheD.

0 голосов
/ 09 февраля 2011

Мы использовали БД для хранения значений конфигурации и ehcache, чтобы избежать большого количества обращений к БД.Таким образом, вам не нужно беспокоиться об использовании памяти (она будет использовать любую имеющуюся у вас память).

EhCache - одно из многих доступных решений для кэширования БД, которое можно настроить поверх JPA и т. Д.

Вы можете настроить ehcache (или многих других провайдеров кеша) так, чтобы таблицы считались доступными только для чтения, и в этом случае он будет отправляться в БД только в том случае, если явно указано, что кеш недействителен.Это работает довольно хорошо.Затраты становятся видимыми, хотя, когда чтение происходит очень часто (например, 100 / сек), но обычно сохраняя значение конфигурации в локальной переменной и избегая чтения внутри циклов, передавая его через стек методов во время вызова, достаточно хорошо это смягчает.

Хранение значений в Singleton как java-объектах работает лучше, но если вы хотите изменить их без приложения.Запустите, это становится немного сложным.

Вот простой способ достижения динамической конфигурации с объектами Java:

private volatile ImmutableMap<String,Object> param_value

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

По сути, я бы рекомендовал использоватьБД и некоторый поставщик кеша, если эта часть кода действительно не требует высокой производительности.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...