Некоторые вопросы о подключении пула в приложении сервлета

Question

Я новичок в java в дизайне веб-приложений, и я удивляюсь, сколько вещей у меня сейчас нет.
В частности, у меня возникают проблемы с пониманием того, как контейнеры сервлетов управляют такими ресурсами, как классы объединения пулов.

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

Например, во многих примерах я увидел, что определенный класс (скажем, ComboPooledDataSource) создается в методе init() сервлета, и здесь я немного запутываюсь. Я имею в виду, я думаю, что система объединения соединений должна существовать и иметь отдельную жизнь по отношению ко всем сервлетам, которые нуждаются в соединении, иначе это не имеет смысла. Поэтому я считаю, что нижеприведенный класс может быть потоком, который запускается один раз из первого сервлета, который вызывает метод init, а затем он продолжает существовать, пока кто-то не прерывает его. Это верно? Если нет, то как это работает?

В любом случае, когда я запускаю этот класс, он распределяется между всеми сервлетами в контексте (я имею в виду все сервлеты, которые вызывают его в методе init)?

Другие примеры создают систему объединения пулов в качестве ресурса, например, определяя его в контексте .xml, а затем любой сервлет, которому требуется соединение, просто должен получить к нему доступ через JNDI (JNDI правильно?). То, что я понял (или я думаю), заключается в том, что в этом случае поток, который будет запускать систему объединения, запускается, когда приложение запускается, и каждый сервлет может получить к нему доступ, когда захочет. Это верно?

В этом случае я могу изменить свойства системы пула соединений с помощью сервлета или среды выполнения фонового потока? (например, если я хочу изменить количество подключений в зависимости от статистики по количеству запросов и т. д.)

Если я хочу создать разные пулы (например, я хочу разделить доступ к базе данных N разные базы данных или я хочу получить доступ с использованием разных имен пользователей) мне нужно создать столько ресурсов, сколько требуется для другого типа соединения?

Есть ли «лучший» способ среди этих двух или они эквивалентны?

Answer 1

Используете ли вы Tomcat для запуска своих сервлетов? У Tomcat 7 есть новое решение для объединения, которое вы можете исследовать. Tomcat также включает библиотеки dbcp, которые вы можете использовать, установив фабрику = "org.apache.tomcat.dbcp.dbcp.BasicDataSourceFactory". Пулы DBCP управляются самостоятельно, и вы можете определить значения конфигурации в файле context.xml. Я не знаю, как изменить эти значения на лету. Я считаю, что пул Tomcat 7 использует ту же конфигурацию, что и DBCP, с несколькими дополнительными параметрами для преобразования между двумя простыми. Мы используем DBCP во всех наших приложениях и не испытывали проблем, поэтому я не использовал пул Tomcat 7. Я думаю, вам нужно создать множество пулов для обработки большинства ваших требований.

Answer 2

Это упрощает использование обслуживания сервера webapp и (Tomcat).
Вы описали 2 случая использования:

1. пул соединений используется один веб-приложение
2. пул соединений совместно WebApps

Первый случай подходит для «простота использования»: вы можете удалите файл войны на любом сервере Tomcat и он будет работать (например,Jenkins поставляет такой файл войны), так как webapp содержит весь код, необходимый для доступа к базе данных. Не нужно изменять конфигурацию сервера Tomcat и перезапускать его.
Если я могу, мне нравится доставлять такие военные файлы, так как меньше вещей может пойти не так (например, никаких столкновений с конфигурацией для других webapps). Вы можете сделать это еще дальше, поставив Tomcat, встроенный в приложение (для этого вам не нужен сервер Tomcat, примерный проект - here).

Обратите внимание, что открытие пула подключения к базе данных (предпочтительно через ServletContextListener.contextInitialized, а не сервлет) и его закрытие (через contextDestroyed) не связано с запуском и остановкой потока. Реализация пула может решить начать фоновый поток (например, удалить незанятые и/или оставленные соединения), но это не обязательно.

Второй корпус подходит для нескольких webapps, которые имеют общую землю. Например, если несколько webapps, все запущенные на одном сервере Tomcat, используют одну и ту же базу данных, это экономит время и усилия, если на сервере Tomcat уже есть пул соединений, доступный для разных веб-приложений (через JNDI). Сервер Tomcat может содержать программное обеспечение драйвера JDBC и программное обеспечение пула соединений в каталоге «lib», а конфигурация выполняется один раз в файле context.xml сервера. Если изменения базы данных или разные (исправленные) программные компоненты необходимы, необходимо обновить только сервер tomcat, и все веб-приложения могут оставаться неизменными. В этом случае обновление сервера Tomcat вместо каждого webapp намного проще.

Второй случай также более подходит для мониторинга: есть хороший шанс, что вы можете контролировать пул соединений через JMX. Такой вид мониторинга может быть недоступен в первом случае.

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

Для разделения базы данных на N разных баз данных потребуется отдельный пул соединений для каждой базы данных, если только это не «только для чтения», и в этом случае вы также можете использовать балансировщик нагрузки.

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