Источник данных Microsoft JDBC Driver для SQL Server (группы доступности AlwaysOn)
У меня есть вопрос, связанный со сценарием при подключении из приложения Java с помощью Microsoft JDBC Driver 4.0 к SQL Server 2014 с AlwaysOn Группы доступности созданы для высокой доступности.
С этой настройкой мы будем подключаться к прослушивателю группы доступности (указанному в строке подключения db вместо любого конкретного экземпляра), так что переключение при сбое БД и т. Д. Будет корректно обработано слушателем, и он попытается подключиться к следующий доступный экземпляр негласно, если текущий первичный сервер выходит из строя в кластере AG.
Вопрос (ы) у меня есть,
В источнике данных, который настроен на стороне сервера приложений j2ee (мы используем WebSphere), что происходит с теми соединениями, которые уже объединены источником данных?
Когда база данных выйдет из строя, хотя прослушиватель AG попытается повторно подключиться на стороне базы данных к следующей доступной БД, будет ли прослушиватель AG также через драйвер jdbc отправлять событие или что-то в источник данных, созданный на сервере приложений, и делать убедитесь, что те соединения, которые уже объединены в источнике данных для отбрасывания, должны создать новые для того, чтобы транзакции на стороне приложения не потерпели неудачу (хотя они могут некоторое время, пока не будут созданы новые соединения и не произойдет сбой), или приложение java должен выяснить только после запроса его из источника данных?
2 ответа
WebSphere Application Server способен справиться с плохими соединениями и удаляет их из пула. Точно, когда это произойдет, зависит от некоторых настраиваемых параметров и от того, насколько полно драйвер JDBC Microsoft использует преимущества API javax.sql.ConnectionEventListener для отправки уведомлений на сервер приложений. В идеальном случае, когда драйвер JDBC немедленно отправляет событие connectionErrorOccurred для всех соединений, WebSphere Application Server отвечает, удаляя все эти соединения из пула и помечая любое соединение, которое в данный момент используется, как плохое, чтобы оно не возвращалось. в пул, как только приложение закрывает дескриптор. В отсутствие этого WebSphere Application Server обнаружит первое плохое соединение при следующем использовании приложением. Он обнаруживается либо событием connectionErrorOcurred, которое отправляется драйвером JDBC в то время, либо отсутствует при проверке кода SQLState/error исключения для известных индикаторов плохих соединений. Затем WebSphere Application Server выполняет очистку плохих соединений из пула в соответствии с настроенной политикой очистки. Есть 3 варианта:
- Политика очистки всего пула - все соединения удаляются из пула, а используемые соединения помечаются как плохие, чтобы они не объединялись в пул.
- Политика очистки только при сбое соединения - только конкретное соединение, на котором действительно произошла ошибка, удаляется из пула или помечается как плохое и не возвращается в пул
- Политика очистки всех соединений - все соединения проверены на валидность (API Connection.isValid), и соединения, признанные плохими, удаляются из пула или помечаются как плохие и не возвращаются в пул. Соединения, признанные действительными, остаются в пуле и продолжают использоваться.
Из вашего описания я не уверен, используете ли вы традиционный WebSphere Application Server или Liberty. Традиционно, существует дополнительная опция для предварительного тестирования соединений, поскольку они передаются из пула, но имейте в виду, что включение этого может повлиять на производительность. Тем не менее, одна вещь, о которой нужно знать, это то, что независимо от любого из вышеперечисленного, ваше приложение всегда должно быть способным обрабатывать возможность ошибок из-за плохих соединений (даже если пул соединений очищен, соединения могут испортиться во время использования) и ответьте, запросив новое соединение и повторив операцию в новой транзакции.
Версия 4 этого драйвера JDBC для SQL Server устарела и ничего не знает о постоянно включенной функции.
Любой пул соединений с источником данных может быть настроен для проверки состояния соединения из пула перед передачей его клиенту. Если соединение не может быть использовано, пул создаст новое. Это верно для всех поставщиков и версий. Я верю, что это лучшее, что ты можешь сделать.