Когда вы проверяете соединения в пуле соединений?

Question

Я реализую пул соединений в Java (то есть пул java.sql.Connection s). Когда я должен проверить, что соединения все еще действительны? Я не хочу делать это, прежде чем одолжить их. Должен ли я сделать это, когда они возвращаются? Каждый раз? Есть ли умный способ запланировать проверку?

Answer 1

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

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

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

Насколько я понимаю, вы пишете свой собственный текст по уважительной причине, поскольку существует множество очень хороших пулов с открытым исходным кодом, которые вы можете использовать, например: Джакарта DBCP & C3P0 и многие другие

Shawn

Answer 2

Имейте поток наблюдения, который гарантирует, что после X секунд в пуле без использования выдается фиктивный запрос (сердцебиение), такой как «выберите 1 из двойного» с оракулом. Это должно поддержать их.

Answer 3

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

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

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

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

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

Answer 4

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

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

Answer 5

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

1. Не доставлять неверный объект подключения клиенту
2. Не требуется много времени для установления соединения (т. Е. Не начинайте устанавливать соединение, когда они у вашей двери просят его одолжить).

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

Конечно, два события, к которым вы можете привязать: 1) новый запрос на соединение 2) закрытый запрос на соединение.

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

После запроса на закрытое соединение - проверьте правильность закрытого соединения, при необходимости пополните пул.

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