#java #mysql #spring #connection-timeout #communicationexception
#java #mysql #весна #время ожидания соединения #исключение communicationexception
Вопрос:
Я использую Java с SpringFramework для программирования базы данных на сервере Mysql с использованием класса JdbcTemplate.
Использование org.apache.commons.dbcp.BasicDataSource в качестве источника данных БД.
Иногда, когда соединения простаивают в течение длительного времени, CommunicationException выдается следующее сообщение:
The last packet successfully received from the server was XXXXX milliseconds ago.
Я не хочу решать эту проблему, добавляя параметр autoReconnect к соединению или добавляя свойство, которое будет выполняться select 1 перед каждым запросом, чтобы убедиться, что соединение правильно открыто. Я также не хочу касаться конфигурации сервера mysql и повышать значения таймаута.
Что я хотел бы сделать, так это правильно обработать это исключение.
Я думал о том, чтобы перехватить CommunicationException и просто повторить попытку до тех пор, пока она не завершится успешно, и если она завершится неудачей более X раз, то выдать исключение, которое показывает, что повторная попытка X раз не удалась.
- у кого-нибудь есть другие идеи, как справиться с этой проблемой?
- как вам моя идея? 🙂
- может быть, в springframework есть что-то, что делает это для меня автоматически, и я пропустил это?
любая информация будет с благодарностью принята.
Спасибо!
Комментарии:
1. Почему вы не хотите использовать автоматическое подключение?
2. я читал, что параметр autoReconnect устарел
3. «Не рекомендуется использовать опцию autoReconnect, поскольку не существует безопасного способа повторного подключения к серверу MySQL без риска некоторого повреждения состояния соединения или информации о состоянии базы данных. Вместо этого вы должны использовать пул соединений, который позволит вашему приложению подключаться к серверу MySQL, используя доступное соединение из пула. Средство автоматического подключения устарело и может быть удалено в будущей версии. «, из dev.mysql.com/doc/refman/5.1/en /…
Ответ №1:
Если ваш запрос перезапускается, возможно, имеет смысл повторить попытку. Я знаю, что мы делаем это местами, и это отлично работает для нечетных временных сбоев. Мы регистрируем событие, хотя оно действительно должно быть редким.
Сбои соединения являются частью жизни и должны обрабатываться иначе, чем тайм-ауты соединения.
Хотя у вас должен быть разумный способ обработки сбоя соединения, которое у вас «под рукой», если вы не удерживаете соединения слишком долго, вы также можете посмотреть свойства testOnBorrow and testOnReturn BasicDataSource . Это не обязательно означает тестовый выбор перед каждым запросом, если только вы действительно не собираете дескриптор перед каждым запросом.
Если у вас много подключений в пуле, и они используются недостаточно часто, чтобы остановить время ожидания, то это действительно ошибка конфигурации. Написание кода, чтобы избежать этого, кажется немного отсталым.