|
|
|
Как отреагировать на плохое отключение клиента ?
|
|||
|---|---|---|---|
|
#18+
Хотелось бы заставить сервер запустить мою процедуру если клиент отпал не по своей воле (свет вырубили). Взможно ли это ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.03.2004, 12:26 |
|
||
|
Как отреагировать на плохое отключение клиента ?
|
|||
|---|---|---|---|
|
#18+
Здесь можно вяло демагогически порассуждать про наличие некоего процесса "рядом" с сервером, который ловит дисконнект, принимает решение и инициализирует что-либо... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.03.2004, 12:31 |
|
||
|
Как отреагировать на плохое отключение клиента ?
|
|||
|---|---|---|---|
|
#18+
> Johnmen Ну а как его поймать-то ентот дисконнект ? Сервер его сразу как-то обнаруживает или с помощью регулярного опроса живих клиентов ? Есть ли в сервере какой-то таймер, чтоб процедуру регулярно вызывать ? - я бы тогда и сам это как-то организовал. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.03.2004, 13:10 |
|
||
|
Как отреагировать на плохое отключение клиента ?
|
|||
|---|---|---|---|
|
#18+
Если у тебя SS, а не CS и юзеры все ходят под разными логинами, то напиши програмку, которая регулярно дёргает isc_database_info с параметром isc_info_user_names. И смотри, кто "выбыл из игры". Если пишешь на Delphi, или CBuilder, можешь воспользоваться компонентом TIBDatabaseInfo. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.03.2004, 13:53 |
|
||
|
Как отреагировать на плохое отключение клиента ?
|
|||
|---|---|---|---|
|
#18+
У меня по Линуксом в firebird.log вот такая запись: FB 1.5 dbserver (Server) Mon Mar 1 15:17:12 2004 Super Server/main: Bad client socket, send() resulted in SIGPIPE, caught by server client exited improperly or crashed ???? Может периодическая обработка этого файла как то может помочь? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.03.2004, 14:16 |
|
||
|
Как отреагировать на плохое отключение клиента ?
|
|||
|---|---|---|---|
|
#18+
> мимопроходящему. Выходит так, что нужен дополнительный клиент при сервере, который следит за порядком. Как-то не красиво. Сам IB должен бы давать средства убрать ссор за безвременно погибшим клиентом. Еще немного подожду, может кто-чего досоветует, а нет - будет по-твоему. Спасибо с уважением. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.03.2004, 14:32 |
|
||
|
Как отреагировать на плохое отключение клиента ?
|
|||
|---|---|---|---|
|
#18+
VVDСам IB должен бы давать средства убрать ссор за безвременно погибшим клиентом. Это какой такой мусор ты имеешь в виду ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.03.2004, 14:39 |
|
||
|
Как отреагировать на плохое отключение клиента ?
|
|||
|---|---|---|---|
|
#18+
> мимопроходящему. Клиент (портье) начинает поселять (вносить данные) гостя в комнату и делает блокировочную пометку в БД, чтоб никто туда (в енту комнату) больше не лез. Закончит поселение и снимает блокировку. Но если свет у портье вырубили - так и будет висеть блокировка - никто с комнатой больше работать не может. Хуже всего, что непонятно - не то у кого-то комп упал, не то портье шнурок съел и по нужде сидит. Т.е. мусор производственный. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.03.2004, 14:50 |
|
||
|
Как отреагировать на плохое отключение клиента ?
|
|||
|---|---|---|---|
|
#18+
Видимо ты не так блокируешь записи. Читай тут . ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.03.2004, 14:55 |
|
||
|
Как отреагировать на плохое отключение клиента ?
|
|||
|---|---|---|---|
|
#18+
Пусть портье сделает холостой апдейт записи "комнаты" перед началом процедуры заселения и в одной транзакции с оной. А конкурирующие товарищи нормально обрабатывают исключение isc_lock_conflict. Тогда всем будет щастье и никакого "производственного мусора" в БД не будет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.03.2004, 14:58 |
|
||
|
Как отреагировать на плохое отключение клиента ?
|
|||
|---|---|---|---|
|
#18+
> мимопроходящему. Плохо я выразился. Реально никаких блокировок записей не делается. Просто после начала поселения (выселения бронирования и т.п.) одним из юзеров в таблице комнат в соответствующих полях отмечается кто и зачем занял комнату и чтоб все это видели она начинает всюду подмигивать. А в БД записывется, чтобы это смог увидеть даже только что зашедший в систему. Блокировка самих записей малоинформативна с тоски зрения кто и зачем блокирует номер. Что-то много написал - но не вытирать же. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.03.2004, 15:18 |
|
||
|
Как отреагировать на плохое отключение клиента ?
|
|||
|---|---|---|---|
|
#18+
> dimitr Другие портье наперед должны видеть, что номер уже в работе (мигает, например) и описать клиенту (напр, по телефону) ситуацию. А начинать перебором тыкать по комнатам для бронирования - может пропустит, а может lock_conflict - многовато клиенту ждать и платить, хотя и так, конечно, можно. До сих пор разводом умерших подключений у меня Midas AppServer занимался. Но во многих случаях меня (скорее клиентов) он уже достал. Решил, что поскольку особо много тут счета нет - вернусь на двузвенку. Но вот проблемы таки полезли. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.03.2004, 15:38 |
|
||
|
Как отреагировать на плохое отключение клиента ?
|
|||
|---|---|---|---|
|
#18+
Понятно. В моей практике была похожая задача с резервированием и продажей билетов. Делали так: когда оператор резервирует место, в специальное поле пишется timestamp - дата и время, когда оная резервация была произведена. Освобождение неподтверждённых резервов делали по таймеру. Для этого была написана небольшая програмка, которая с периодичностью в 30 сек сканировала таблицу в поисках неподтверждённых резрваций, у которых время превысило 1 час (по ТЗ), с момента резервирования. Такие записи автоматом возвращались в состояние "свободно". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.03.2004, 15:38 |
|
||
|
|

start [/forum/topic.php?fid=40&msg=32429501&tid=1579100]: |
0ms |
get settings: |
4ms |
get forum list: |
11ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
161ms |
get topic data: |
7ms |
get forum data: |
2ms |
get page messages: |
52ms |
get tp. blocked users: |
1ms |
| others: | 203ms |
| total: | 447ms |

| 0 / 0 |
