Лучший способ справиться с соединением с базой данных для сервлета Java
Для проекта, над которым я работаю, мое приложение должно выпустить сценарий оболочки со всеми командами git для инициализации / фиксации / отправки во внешний репозиторий. Файл ~ / .ssh / config запрещен, поэтому у меня есть открытый / закрытый ключи в каталоге приложения. Я использовал ответ Вальлака. Вот что я должен был сделать в своем сценарии оболочки, чтобы использовать мой ключ:
eval `/usr/bin/ssh-agent`
ssh-add /path/to/.ssh/id_rsa
надеюсь, что это кому-то поможет
1 ответ
Как все говорят, вам нужно использовать пул соединений. Зачем? Что случилось? И т.д.
Что не так с вашим решением
Я знаю это, так как когда-то думал, что это была хорошая идея. Проблема двоякая:
- Все потоки (запросы сервлетов обслуживаются по одному потоку на каждый) будут использовать одно и то же соединение. Таким образом, запросы будут обрабатываться по одному. Это очень медленно, даже если вы просто сидите в одном браузере и нажимаете клавишу F5. Попробуйте: этот материал звучит высокоуровнево и абстрактно, но он эмпирический и поддается проверке.
- Если соединение разрывается по какой-либо причине, метод init не будет вызываться снова (потому что сервлет не будет выведен из эксплуатации). Не пытайтесь решить эту проблему, помещая try-catch в doGet или doPost, потому что тогда вы попадете в ад (что-то вроде написания сервера приложений без запроса).
- Вопреки тому, что можно было подумать, у вас не будет проблем с транзакциями, поскольку начало транзакции связывается с потоком, а не только с подключение. Возможно, я ошибаюсь, но так как это в любом случае плохое решение, не переживайте.
Почему пул подключений
Пулы подключений дают вам целый ряд преимуществ, но больше всего они решают проблемы
- ] Реальное подключение к базе данных стоит дорого. Пул соединений всегда имеет несколько дополнительных соединений и дает вам одно из них.
- Если соединения терпят неудачу, пул соединений знает, как открыть новое
- Очень важно: каждый поток получает собственное соединение. Это означает, что потоки обрабатываются там, где они должны быть: на уровне БД. БД очень эффективны и могут легко обрабатывать параллельные запросы.
- Прочие вещи (например, централизация расположения строк подключения JDBC и т. Д.), Но об этом есть миллионы статей, книг и т. Д.
Когда устанавливать соединение
Где-то в стеке вызовов, инициированном в вашем сервис-делегат (doPost, doGet, doDisco, что угодно) вы должны получить соединение, а затем вы должны сделать правильные вещи и вернуть его в блоке finally. Я должен упомянуть, что чувак, главный архитектор C #, однажды сказал, что вы должны использовать finally блоков в 100 раз больше, чем catch блоков. Истинные слова никогда не произносятся ...
Какой пул соединений
Вы находитесь в сервлете, поэтому вам следует использовать пул соединений, который предоставляет контейнер. Ваш код JNDI будет полностью нормальным, за исключением того, как вы устанавливаете соединение. Насколько я знаю, все контейнеры сервлетов имеют пулы соединений.
В некоторых комментариях к ответам выше предлагается использовать вместо этого определенный API пула соединений. Ваша WAR должна быть переносимой и «просто развертываемой». Я считаю, что это в корне неверно. Если вы используете пул соединений, предоставленный вашим контейнером, ваше приложение будет развертываться в контейнерах, охватывающих несколько машин, и все те модные вещи, которые предоставляет спецификация Java EE. Да, нужно будет написать дескрипторы развертывания для конкретных контейнеров, но это путь EE, мон.
Один из комментаторов упоминает, что определенные пулы соединений, предоставляемые контейнером, не работают с драйверами JDBC (он / она упоминает Websphere). Это звучит совершенно неправдоподобно и нелепо, так что, вероятно, это правда. Когда такое случается, бросайте все, что вы «должны делать» в мусор и делайте все, что можете. Иногда нам за это платят :)