Форум по InterBase, Firebird и Yaffil
http://www.ibaseforum.ru/
Да элементарно: юзер выключил а затем включил сервак, или на клиенте в винде вынули сетевой кабель, а затем подключили. Все эти причины ведут к обрыву TCP подключения и мне надо это отлавливать и переподключаться.kdv писал(а):что-то я не встречал, чтобы вызов этой функции завершался с ошибкой, если БД не битая...
Сетевые ошибки имеют свои собственные кодыArtDen писал(а):Да элементарно: юзер выключил а затем включил сервак, или на клиенте в винде вынули сетевой кабель, а затем подключили. Все эти причины ведут к обрыву TCP подключения и мне надо это отлавливать и переподключаться.kdv писал(а):что-то я не встречал, чтобы вызов этой функции завершался с ошибкой, если БД не битая...
Что "это" ?ArtDen писал(а):Тот подход, что я описал в первом сообщении - работает на клиенте безо всяких проблем. Вот только как это сказывается на сервере?
Я и не отрицаю. Просто хочется иметь простой способ узнать, что соединение отвалилось и своевременно переподключиться перед работой с данными. В принципе, IBPP позволяет это сделать через отлов события отключения, но этот вариант меня не устраиваетhvlad писал(а):Сетевые ошибки имеют свои собственные коды
"Это" - это вызов database_info для тестирования подключения.hvlad писал(а):Что "это" ?
соединение отвалилось когда оно отвалилось, и когда сетевая подсистема ОС сообщит об этом клиентской части.хочется иметь простой способ узнать, что соединение отвалилось и своевременно переподключиться перед работой с данными
нет "события отключения". Есть ошибка при попытке работать с сервером, из-за того что соединение отвалилось.позволяет это сделать через отлов события отключения, но этот вариант меня не устраивает
Вопрос был такой: насколько это правильное решение - запрашивать статистику сервера для того, чтобы узнать не отвалилось ли TCP соединение и при необходимости переподключиться. Если моё решение неправильное, то буду рад выслушать любое другое или вообще узнать любые другие мнения по этому вопросу.kdv писал(а):какие-то противоречивые желания или вопросы. "я знаю как это происходит, но ..."
Не занимался этим вопросом, но вашему авторитету доверяю полностьюkdv писал(а):нет "события отключения". Есть ошибка при попытке работать с сервером, из-за того что соединение отвалилось.
На них и нужно ориентироваться.ArtDen писал(а):Я и не отрицаю. Просто хочется иметь простой способ узнать, что соединение отвалилось и своевременно переподключиться перед работой с данными.hvlad писал(а):Сетевые ошибки имеют свои собственные коды
Т.е. ты перед каждым вызовом ("работой с данными") таким образом тестируешь подключение ? А смысл ?ArtDen писал(а):"Это" - это вызов database_info для тестирования подключения.hvlad писал(а):Что "это" ?
Смысл в том, чтобы узнать об отвалившемся соединении перед работой с данными, а не в процессе. В моём случае последовательность такая: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 писал(а):Перечисли кучу, я поправлю
Я пришёл с вопросом. Проблем пока у меня нет. И ошибки я отлавливаю, даже в том случае, если соединение отвалилось в процессе работы с данными, так что не надо меня упрекать, что создаю себе проблемыhvlad писал(а):С проблемами ты уже пришёл. Пока что они ещё не такие большие...
А говорил - кучаArtDen писал(а):Наиболее подходящими мне кажутся следующие:hvlad писал(а):Перечисли кучу, я поправлю
isc_network_error
isc_net_read_err
isc_net_write_err
Тебе на вопрос ответили. Ответ тебя не устраивает. Так какого эту жвачку жевать ?ArtDen писал(а):Я пришёл с вопросом. Проблем пока у меня нет. И ошибки я отлавливаю, даже в том случае, если соединение отвалилось в процессе работы с данными, так что не надо меня упрекать, что создаю себе проблемыhvlad писал(а):С проблемами ты уже пришёл. Пока что они ещё не такие большие...