как правильно обработать ошибку простоя соединения - PullRequest
0 голосов
/ 18 октября 2011

Я использую Java с SpringFramework для программирования баз данных на Mysql Server с использованием класса 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 раз не удалась.справиться с этой проблемой?

как моя идея?:) Может быть, в Springframe есть что-то, что автоматически делает это для меня, и я пропустил это?

любая информация будет принята с благодарностью.

спасибо!

1 Ответ

1 голос
/ 18 октября 2011

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

Соединение Сбои являются частью жизни и должны обрабатываться иначе, чем соединение Таймауты .

Хотя у вас должен быть вменяемый способ обработки соединения, которое у вас «в руке» не удается, если вы не удерживаете соединения слишком долго, вы также можете взглянуть на свойства testOnBorrow и testOnReturnBasicDataSource.Это не обязательно означает выбор теста перед каждым запросом, если только вы на самом деле не собираете дескриптор перед каждым запросом.

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

...