---|Ветка была без названия|---

← →
Vasilii (2002-01-17 11:54) [0]

Hello всем!
При отключении удаленной машины IB Server(IB Guardian) продолжает считать соединение с базой действующим.
Как с этим бороться?

← →
Alexandr (2002-01-17 13:29) [1]

никак

← →
Vasilii (2002-01-17 15:34) [2]

Тогда иначе: Известно, что соединение "А" - зависло. Требуется оборвать это соединение, не оборвав остальные ("B","C"..."Y").

← →
Romkin (2002-01-17 15:38) [3]

зайди в файл IbConfig (он текстовый), убери # перед CONNECTION_TIMEOUT и установи напротив кол-во секунд, через которые молчащее соединение вырубается.
Если не ошибаюсь, IB посылает пустые пакеты клиенту, и если ответа на них нет за указанное время - отрубает соединениe

← →
Fareader (2002-01-17 15:39) [4]

Прийдется гасить всех :(

← →
Vasilii (2002-01-17 16:04) [5]

>Romkin
Вариант не прошел. Изначально строки #CONNECTION_TIMEOUT у меня
в IbConfig вообще не было. После добавления - результат
отсутствует. IBServer разрывает зависшее соединение только
после того, как выключенный компьютер снова оказывается в сети.
>Fareader
20 человек из разных углов здания прибегут топтать меня ногами
если я их всех отключу. Опасно.

← →
Alexandr (2002-01-18 07:24) [6]

это известная проблема в Interbase.
Факты на этот счет

Соединение действительно само закончится, когда сервер попробует передать данные клиенту, а клиента уже нет. До тех под сервер будет молотить то, что уже никому не надо.
Это имеет особую актуальность при выполнении долгих запросов.
В Interbase SuperServer на платформе Windows это особенно актуально т.к. один длинный запрос подвешивает осталых.
Выход использовать IB Classic на Linux например. Там с этим гораздо легче. Или использовать сборку Firebird называемую Yaffil
см. тут http://www.private.peterlink.ru/rcav/.
Или есть выриант прерывания длинных запросов с помощью генераторов и периодических проверок. Если надо, напишу про это подробнее.

А вообще-то мое мнение, подтвержденное жизнью- длинных запросов не должно быть. Это либо неправильно написанные запросы,либо надо менять логуку/структуру базы данных либо их выполнять надо когда с базой никто не работает - здесь тоже есть дольшие наработки - если надо поделюсь.

так что вот так.

← →
Vasilii (2002-01-18 14:16) [7]

В принципе, при ближайшем рассмотрении, не так все и плохо. Минут через 5-7 сервак отпускает. Жить можно.

← →
Alexandr (2002-01-18 14:18) [8]

угу, когда запрос выполнится.

Вот только как жить эти 5-7 минут.
Ты привел запрос-мы бы посмотрели, чего ты там натворил, ты не поверишь, но твой запрос, может оказаться, может выполниться на несколько секунд, если ты его неправильно написал, или индекс какой не создал, или еще чего...

← →
Vasilii (2002-01-18 15:08) [9]

Да не запрос там. Транзакция висит незавершенная.

← →
Alexandr (2002-01-21 09:33) [10]

Теперь понял.
ну и фиг с ней.
Пусть висит. Повисит она немного и сама слезет.
Тебе - то что с нее?
ну хочешь, отключи всех принудительно.
а так по TimeOut в конфиге сервак должен их Rollback сделать

← →
Vasilii (2002-01-21 10:18) [11]

Всех нельзя.
До тех пор, пока висит эта транзакция, одна из записей в таблице для остальных пользователей является ReadOnly (по логике программы). На некоторое время получается неприятное положение: с записью ни кто не работает, но и изменять ее ни кто не может.
Пришлось встроить в серверный модуль "ручное освобождение занятого ресурса", которое используется при гневных возмущенных криках пользователей.

← →
Alexandr (2002-01-21 10:32) [12]

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

Изменения нужно в базе делать сразу и быстро, что бы клиент зависнуть (отключиться не успел) и чтобы другие не уведели залоченных данных.

Или я опять не про то?

← →
Vasilii (2002-01-21 12:33) [13]

"...Не то чтобы совсем не попал. Не попал в шарик ..."
А.А.Милн "Винни Пух и все,все,все"
Представь себе, к примеру, совместный доступ нескольких пользователей к одному документу. Тот, кто открыл его первым имеет полный контроль над документом. Остальные могут его только читать или использовать в качестве шаблона. У меня похожая итория.

← →
Vasilii (2002-01-21 12:34) [14]

Считается, что ресурс занят т.к. не было команды на его освобождение.

← →
Alexandr (2002-01-22 06:44) [15]

понятно. И в чем проблема?
делаешь холостой update этому документу в начале редактирования, и никто кроме тебя его не изменит.
А если ты отвалишься, то сервер rollback тебе сам сделает. И все.

Надеюсь, что такое холостой update объяснять не нужно...

← →
Vasilii (2002-01-22 09:00) [16]

Примерно понятно. У меня решается установкой "Т" в поле ReadyToUse из-за необходимости сортировки по занят/свободен.

← →
Alexandr (2002-01-22 11:41) [17]

да, вот эта установка T
как раз все тебе портит.
тут надо подумать, как сделать что бы эта T откатывалать сама, если клиент отвалился...

← →
Vasilii (2002-01-22 12:13) [18]

Кроме ReadyToUse еще есть поля, содержащие время/дату и имя пользователя, совершившего последнее изменение записи (в данном случае изменившего "F" на "Т"). Серверный модуль периодически (1..30 сек) производит проверку таблицы на занятость и наличие подключений. В случае, если запись в таблице помечена, как ReadOnly пользователем, имя которого отсутствует среди подключенных, то такая запись освобождается. Но! И тут мы возвращаемся к началу дискуссии. Соединение считается СУЩЕСТВУЮЩИМ, а на самом деле его нет!

← →
Alexandr (2002-01-22 12:26) [19]

понятно.
Заставь пользовательские программы обновлять поле времени каждую минуту, например, если он очередной раз не обновил поле, то значит клиента нет, или он завис.
Т.о. ты создашь свой механизм подтверждения, что клиент живой вместо Interbase"овского наличия коннекта.
И в своем серверном можуле проверяй, чтобы все записи были за последнюю минуту, как только старше-значит клиент отвалился.

Тут будет проблема в том, что если клиентский комп. будет оч. сильно загружен, то он эту минуту может пропустить, но при этом работать и выдать подтверждение позже, но это все можно настроить.

← →
Ujin_m (2002-01-22 12:31) [20]

A esli sleduuschii algorithm:
Klient (rabotauschii s documentom v R/W mode)kajduu minutu delaet update nekoi zapisi i stavit tuda tekuschee vremia i datu. Vse chto nado delat server eto proverit esli eta zapis ne prosrochena. Esli da to schitat klienta ne podkluchennum.

← →
Alexandr (2002-01-22 12:41) [21]

2Ujin_m:
ну а чего за мной повторять-то

← →
Vasilii (2002-01-22 12:55) [22]

Вариант! Попробую. Спасибо!

---|Ветка была без названия|--- Найти похожие ветки