Tomcat пула соединений JDBC: testOnBorrow против testWhileIdle

Question

По различным причинам соединений в пуле может стать недействительным: сервер тайм-аут соединения, проблем в сети ...

Я понимаю, что пул соединений Tomcat JDBC не предоставляет гарантию о действительность подключений, которые она предоставляет приложению.

Чтобы предотвратить (фактически только снизить риск) получение недопустимого соединения из пула, решение, похоже, является конфигурацией проверки соединений. Проверка соединения означает запуск очень простого запроса в базе данных (например, SELECT 1; в MySQL).

Пул соединений Tomcat JDBC предлагает несколько вариантов проверки соединения. Эти два, которые я нахожу более интересными, - testOnBorrow и testWhileIdle.

Прежде всего я думал, что testOnBorrow - лучший вариант, поскольку он в основном проверяет соединение, прежде чем предоставлять его в приложение (с максимальной частотой, определяемой validationInterval).

Но после второго, хотя я понял, что тестирование соединения прямо перед его использованием может повлиять на отзывчивость приложения. Таким образом, я, хотя использование testWhileIdle может быть более эффективным, поскольку оно проверяет соединения, пока они не используются.

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

Итак, я спрашиваю: должен ли я использовать testOnBorrow или testWhileIdle или смесь обоих?

На стороне примечания, я удивлен, что validationInterval не относится к testOnReturn, и я действительно не получаю назначение testOnConnect.

Answer 1

Ответ на этот вопрос не на 100%. Это вопрос компромисса и контекста.

• Большую часть времени, testOnBorrow является наименее рискованным, так как она обеспечивает (как может), что до того, как соединение возвращается из пула для вашего использования, базовая проверка исправности было сделано, что клиент и db-сервер находятся на переговорах.
• Он по-прежнему не мешает гоночному состоянию соединения с сервером снижаться, между временем «проверка работоспособности» было сделано &, когда ваше приложение использовало соединение.

• Но, рассматривая это как угловой шкаф, testOnBorrow дает довольно хорошую гарантию.

• Теперь компромисс с тем, что каждый раз, когда вы запрашиваете соединение, на сервер базы данных запрашивается запрос (независимо от того, насколько легкий). Это может быть очень быстро, но стоимость по-прежнему не равна нулю.

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

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

• Он обеспечивает максимальное, что у вас есть хорошее соединение, прежде чем использовать его. Особенно учитывая стоимость (повторная попытка + ручное вмешательство, потеря рабочего процесса и т. Д.) Из-за невозможности восстановления из-за неудачной операции БД.

• Теперь представьте, если у вас есть опция testOnIdle. Это требует, чтобы ваши соединения простаивали (в зависимости от таймаута простоя соединения), прежде чем можно будет проверить проверку работоспособности.

• Это улучшение производительности по сравнению с testOnBorrow, но оно имеет свои недостатки.
  • реального мир приложение-к-DB-соединения не только в холостом режиме ожидания на основе поломки, они могут быть отброшены на основе правил брандмауэра, п/ш заторы, дб-серверном проходит техническое обслуживание/патчи и т.д.
  • Таким образом, он возвращается к измерению данных о том, сколько ошибок соединения наблюдалось в данных, когда у вас не было какой-либо «проверки соединения».
• И одна вещь, чтобы следить за этой опцией, - это то, когда у вас есть бассейн, который работает лучше всего с максимальными соединениями, и ваше приложение работает хорошо, и по какой-либо причине, если ваш db-сервер подвергается перезагрузке или аналогичным образом. Все живые подключения (с точки зрения клиента) теперь будут в основном ошибки, до тех пор, пока не начнется простоя бездействия. Таким образом, ваш db-вопрос (который был бы пожарным) теперь немного усугубляется, пока соединения приложений не улучшатся или не перезапустите приложение.

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

Answer 2

Просто чтобы сообщить об этом, я только что протестировал это, и вы можете использовать как testOnBorrow, так и testOnIdle.

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

Как указано в комментариях, testOnBorrow не требует запроса валидации. Если вы решили сохранить один, это может быть просто выберите:

jdbc.hive.testOnBorrow=true 
jdbc.hive.validationQuery=SELECT 1 

Если вы хотите использовать testWhileIdle, вы можете использовать следующее:

jdbc.testWhileIdle=true 
jdbc.minEvictableIdleTimeMillis=1800000 
jdbc.timeBetweenEvictionRunsMillis=1800000` 

Подробнее о DCHP: https://commons.apache.org/proper/commons-dbcp/configuration.html