Когда не использовать пул соединений с базой данных в Java? [закрытый]



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



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



Так есть ли смысл в использовании пула соединений?



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



Абсолютно ли я придется вызовите close() на моем соединении после того, как я что-то с ним сделаю, или достаточно вызова close() на ResultSet и/или Statement?

535   3  

3 ответов:

Что такое" подключение к базе данных " на самом деле? Это сеанс работы с вашей базой данных, и как таковой:

  • существует состояние сеанса на стороне клиента и на стороне сервера
  • существует транзакция, связанная с этим сеансом

Теперь, поскольку ваше клиентское приложение многопоточно, я подозреваю, что существует только крайне ограниченное число случаев, когда ваша настройка имеет смысл, а именно:

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

Во всех остальных случаях требуется одно соединение на клиентский поток или в реактивной/асинхронной среде требуется по крайней мере одно соединение на изолированное взаимодействие с базой данных. И потому, что это дорого, чтобы создать новые соединения (т. е. инициализировать состояние сеанса на стороне сервера и т. д.) люди просто используют пулы соединений. На самом деле, пул соединений может иметь только одно соединение внутри него (в соответствии с вашим требованием), и это все еще хорошая абстракция для вас, чтобы использовать. Так зачем же писать свой собственный пул соединений?

Что касается ваших конкретных вопросов:

Так есть ли смысл в использовании пула соединений?

За исключением очень тривиальных случаев (см. выше), обычно хорошо иметь пул соединений.

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

Вы могли бы, конечно. Обычно в драйверах JDBC или других клиентских библиотеках есть настройка для предотвращения этих тайм-аутов или повторного подключения.

Идеальным вариантом использования такого подхода является сценарий миграции, или пакетный сценарий, или простой тестовый скрипт, или простое качающееся приложение и т.д. Все они не нуждаются в пуле соединений.

Обязательно ли мне вызывать close() для моего соединения после того, как я что-то с ним сделаю, или достаточно вызвать close() для результирующего набора и/или оператора?

Вы должны вызывать close() по соединениям, полученным из DataSource.getConnection() (например, когда пул соединений реализует DataSource).

Вам не нужно вызывать close() соединения, жизненным циклом которых вы управляете. твой собственный.

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

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

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

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

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

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

Comments

    Ничего не найдено.