Проверка подключения к серверу
Проверка подключения к серверу
В проекте для работы с FB задействована библиотека IBPP. Для проверки, есть ли подключение к серверу, я использую запрос статистики сервера (функция IBPP::Statistics, которая внутри вызывает database_info). Если вызов функции завершился с ошибкой, я переподключаюсь.
Насколько это корректный подход? Может есть более правильное решение?
Насколько это корректный подход? Может есть более правильное решение?
Да элементарно: юзер выключил а затем включил сервак, или на клиенте в винде вынули сетевой кабель, а затем подключили. Все эти причины ведут к обрыву TCP подключения и мне надо это отлавливать и переподключаться.kdv писал(а):что-то я не встречал, чтобы вызов этой функции завершался с ошибкой, если БД не битая...
Тот подход, что я описал в первом сообщении - работает на клиенте безо всяких проблем. Вот только как это сказывается на сервере?
Сетевые ошибки имеют свои собственные кодыArtDen писал(а):Да элементарно: юзер выключил а затем включил сервак, или на клиенте в винде вынули сетевой кабель, а затем подключили. Все эти причины ведут к обрыву TCP подключения и мне надо это отлавливать и переподключаться.kdv писал(а):что-то я не встречал, чтобы вызов этой функции завершался с ошибкой, если БД не битая...
Что "это" ?ArtDen писал(а):Тот подход, что я описал в первом сообщении - работает на клиенте безо всяких проблем. Вот только как это сказывается на сервере?
Я и не отрицаю. Просто хочется иметь простой способ узнать, что соединение отвалилось и своевременно переподключиться перед работой с данными. В принципе, IBPP позволяет это сделать через отлов события отключения, но этот вариант меня не устраиваетhvlad писал(а):Сетевые ошибки имеют свои собственные коды
"Это" - это вызов database_info для тестирования подключения.hvlad писал(а):Что "это" ?
какие-то противоречивые желания или вопросы. "я знаю как это происходит, но ..."
соединение отвалилось когда оно отвалилось, и когда сетевая подсистема ОС сообщит об этом клиентской части.хочется иметь простой способ узнать, что соединение отвалилось и своевременно переподключиться перед работой с данными
нет "события отключения". Есть ошибка при попытке работать с сервером, из-за того что соединение отвалилось.позволяет это сделать через отлов события отключения, но этот вариант меня не устраивает
Вопрос был такой: насколько это правильное решение - запрашивать статистику сервера для того, чтобы узнать не отвалилось ли TCP соединение и при необходимости переподключиться. Если моё решение неправильное, то буду рад выслушать любое другое или вообще узнать любые другие мнения по этому вопросу.kdv писал(а):какие-то противоречивые желания или вопросы. "я знаю как это происходит, но ..."
Не занимался этим вопросом, но вашему авторитету доверяю полностьюkdv писал(а):нет "события отключения". Есть ошибка при попытке работать с сервером, из-за того что соединение отвалилось.
На них и нужно ориентироваться.ArtDen писал(а):Я и не отрицаю. Просто хочется иметь простой способ узнать, что соединение отвалилось и своевременно переподключиться перед работой с данными.hvlad писал(а):Сетевые ошибки имеют свои собственные коды
Т.е. ты перед каждым вызовом ("работой с данными") таким образом тестируешь подключение ? А смысл ?ArtDen писал(а):"Это" - это вызов database_info для тестирования подключения.hvlad писал(а):Что "это" ?
Серверу фиолетово, что ты постоянно дёргаешь database_info, юзеру будет не фиолетово.
Смысл в том, чтобы узнать об отвалившемся соединении перед работой с данными, а не в процессе. В моём случае последовательность такая:hvlad писал(а):Т.е. ты перед каждым вызовом ("работой с данными") таким образом тестируешь подключение ? А смысл ?
Код: Выделить всё
1. Проверка подключения к базе (и переподключение, если подключение отвалилось)
2. Работа с данными
Код: Выделить всё
1. Попытка работы с данными
2. Если попытка завершилась с ошибкой (работы с сетью), то
{
3. Переподключается
4. Повторяем работу с данными
}
А как это будет отображаться на юзере? Или в некоторых случаях запрос статистики может занять длительное время?hvlad писал(а):Серверу фиолетово, что ты постоянно дёргаешь database_info, юзеру будет не фиолетово.
я не знаю, как там в IBPP, но идея при ошибке переоткрывать коннект и повторять действие с данными ужасна.Если отлавливать сетевые ошибки, то последовательность будет такая:
Потому что повторять придется тучу операций, в зависимости от контекста.
Потеря коннекта означает что все, амбец, контекст соединения с сервером утерян, и надо начинать все сначала. Т.е. для клиент-серверных приложений с множеством форм и определенной последовательностью работы это означает необходимость _перезапуска_ приложения.
теоретически, конечно, примитивные приложения-роботы должны реагировать на обрыв коннекта переподсоединением и продолжением работы. Насчет интерактивных - сильно сомневаюсь.
Он просто глупый и ничего не гарантирует.ArtDen писал(а):Смысл в том, чтобы узнать об отвалившемся соединении перед работой с данными, а не в процессе. В моём случае последовательность такая:hvlad писал(а):Т.е. ты перед каждым вызовом ("работой с данными") таким образом тестируешь подключение ? А смысл ?
Если отлавливать сетевые ошибки, то последовательность будет такая:Код: Выделить всё
1. Проверка подключения к базе (и переподключение, если подключение отвалилось) 2. Работа с данными
Как видишь, мой вариант проще.Код: Выделить всё
1. Попытка работы с данными 2. Если попытка завершилась с ошибкой (работы с сетью), то { 3. Переподключается 4. Повторяем работу с данными }
Что ты будешь делать, если коннект порвётся во время твоих действий с данными ?
Запрос-ответ через сеть не за нулевое время ходитArtDen писал(а):А как это будет отображаться на юзере? Или в некоторых случаях запрос статистики может занять длительное время?hvlad писал(а):Серверу фиолетово, что ты постоянно дёргаешь database_info, юзеру будет не фиолетово.
Обрыв коннекта во время операций с данными - это уже второй вопрос. Меня в сейчас первую очередь интересует проверка на наличие соединения.hvlad писал(а):Он просто глупый и ничего не гарантирует.
Что ты будешь делать, если коннект порвётся во время твоих действий с данными ?
Но всё равно быстро, так что это для меня не критично.hvlad писал(а):Запрос-ответ через сеть не за нулевое время ходит
Ну да, сказали по кодам сетевых ошибок отлавливать. Только вот не сказали, какие именно коды использовать. Там их целая куча этих сетевых ошибок.hvlad писал(а):Ты спросил - тебе ответили.
Не понял мысли. Поясните. Зачем я обязательно должен потом кого-то грузить проблемами?hvlad писал(а):Прячь проблемы от себя и дальше, только не нужно других ими потом грузить.
Перечисли кучу, я поправлюArtDen писал(а):Только вот не сказали, какие именно коды использовать. Там их целая куча этих сетевых ошибок.
Ещё раз говорю - твой метод ничего не даёт кроме лишних запросов к серверу.ArtDen писал(а):Не понял мысли. Поясните. Зачем я обязательно должен потом кого-то грузить проблемами?hvlad писал(а):Прячь проблемы от себя и дальше, только не нужно других ими потом грузить.
С проблемами ты уже пришёл. Пока что они ещё не такие большие...
Наиболее подходящими мне кажутся следующие:hvlad писал(а):Перечисли кучу, я поправлю
isc_network_error
isc_net_read_err
isc_net_write_err
Я пришёл с вопросом. Проблем пока у меня нет. И ошибки я отлавливаю, даже в том случае, если соединение отвалилось в процессе работы с данными, так что не надо меня упрекать, что создаю себе проблемыhvlad писал(а):С проблемами ты уже пришёл. Пока что они ещё не такие большие...
А говорил - кучаArtDen писал(а):Наиболее подходящими мне кажутся следующие:hvlad писал(а):Перечисли кучу, я поправлю
isc_network_error
isc_net_read_err
isc_net_write_err
Годится
Тебе на вопрос ответили. Ответ тебя не устраивает. Так какого эту жвачку жевать ?ArtDen писал(а):Я пришёл с вопросом. Проблем пока у меня нет. И ошибки я отлавливаю, даже в том случае, если соединение отвалилось в процессе работы с данными, так что не надо меня упрекать, что создаю себе проблемыhvlad писал(а):С проблемами ты уже пришёл. Пока что они ещё не такие большие...