iBase.ru Forum

День добрый. Столкнулся с проблемой следующего содержания - Есть база, к ней подключаются n-ное количество пользователей, причем один и тот-же пользователь может использовать несколько подключений к базе. А теперь собственно вопрос, как можно проконтролировать что какое-либо соединение еще активно? В теории можно воспользоваться TMP$ATTACHMENTS, но так-как соединений у пользователя может быть больше одного, то не совсем понятно как его отследить. Можно использовать дотолнительную таблицу для хранении информации о входе/выходе, но в случае аварийного завершения работы приложения опять-же не поможет... Мож кто сталкивался. Буду благодарен за совет...

В теории можно воспользоваться TMP$ATTACHMENTS, но так-как соединений у пользователя может быть больше одного, то не совсем понятно как его отследить.

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

Первая глупая идея такова:
Пусть приложение при запуске берёт себе session_id из какого-нибудь специально для этого генератора. И все вызовы процедур выполняет с передачей этого session_id. А напрямую из приложения таблицы не редактировать - пусть этим процедуры занимаются. Таким образом, сервер знает, кто выполняет конкретное действие.
Конечно, тут нужно во всех процедурах этот параметр вводить...

Не все так просто... Как идентифицировать - все понятно, но проблема в том, чтоб отледить активно соединение, или уже нет. Тут хоть ставь таймер на "отстрел" по времени...

Дай определение твоему термину "активное соединение". Слишком много возможных толкований.

Значится, что соединение с базой установленно, и не прервано. Для чего? Чтоб снять все блокировки с записей и таблиц, коии могут редактироваться только монопольльно + ведение лога + и еще много чего полезного

Тут хоть ставь таймер на "отстрел" по времени...

ну и ставьте. проблемы тут нет. лучше правильно написанное приложение, чем елозить по серверу выясняя, кто там каких висяков наоставлял.

MrAndrew писал(а):Значится, что соединение с базой установленно, и не прервано. Для чего? Чтоб снять все блокировки с записей и таблиц, коии могут редактироваться только монопольльно + ведение лога + и еще много чего полезного

Если пользоваться твоим определением - все коннекты всегда являются активными.

Пусть приложение написано правильно, но есть еще и "злобная уборщица со шваброй".... С ней бороться уже бесполезно + хотелось бы чтоб усе было красиво....

to WildSery: Естественно, однако, пользователь блокирует запись и аварийно отваливается.... И все. Так как его уже нет, то и блокировку с записи никто уже не снимет, так как иначе в чем ее смысл?

Тогда при чём тут существующие соединения? Чего-то не догоняю.
Или ты хочешь на сервере прибить соединения, которые не имеют клиента? Тогда это возможно - такие соединения не имеют открытого сокета. Реализация нахождения зависит от платформы. Для Linux - для каждого из gds_inet_server смотрим pid процесса, по pid смотрим открыто ли соединение 3050/tcp или где там у тебя, если не нашли - можно прибивать.

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

Умереть самостоятельно они могут ещё очень не скоро после обрыва соединения. Если процесс висит, а клиента нет - каким образом я могу кого-то угрохать? Приведи пример.

WildSery: Не получиться... Тут судя по всему виновато не совсем точное описание проблемы. Попробую еще раз:

Есть пользователь подключившийся к базе н-раз, при установке соединения он регистрируется в таблице CONNECTED, то есть через генератор код соединения получен, далее ему необходимо изменить запись в таблице, работа с которой, по бизнес-логике возможна только монопольно. Для этого использую метод а-ля 1с то есть через свою таблицу блокировок, (объект, запись, код соединения, флаг блокировки)
После блокировки пользователь благополучно отваливается, соответственно запись более никто изменить не может. Для решения возникшего вопроса требуется отследить а живой ли он еще, ежли нет, то снять блокировку.
Есть таблица текущих соединений TMP$ATTACHMENT содержащая необходимую информацию, и в теории можно было бы взять значение поля TMP$ATTACHMENT_ID для привязки, но, так как соединений у пользователя больше одного, то как его тогда найти, родимого, в этом компоте?, или обойти этот вопрос как-то иначе

to WildSery: таблица connected не системная, а моя. Так сказать для внутреннего пользования... Соответственно при помощи удаления записи из нее я автоматом убираю все текущие блокировки пользователя.

WildSery писал(а):Если процесс висит, а клиента нет - каким образом я могу кого-то угрохать? Приведи пример.

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

Пусть все клиентские приложения по команде (например, event) сообщают о своей активности, ставя флаг в табличке сеансов, предварительно помеченной неактивностью для всех вызывающим эту команду. Ждём небольшое время (может, не все мгновенно откликнулись), а затем рубим те сеансы, которые остались неактивными.

MrAndrew писал(а):Соответственно при помощи удаления записи из нее я автоматом убираю все текущие блокировки пользователя.

А не пойти бы тебе почитать это?..

Dimitry Sibiryakov писал(а):

MrAndrew писал(а):Соответственно при помощи удаления записи из нее я автоматом убираю все текущие блокировки пользователя.

А не пойти бы тебе почитать это?..

Был, читал особенно понравилось - Основной минус тут один: запись может висеть в заблокированном состоянии сколько угодно, поэтому желательно наличие какого-нибудь администратора, который может принудительно разблокировать любую запись.

Так где здесь лекарство, может я просмотрел невнимательно?

WildSery писал(а):Пусть все клиентские приложения по команде (например, event) сообщают о своей активности, ставя флаг в табличке сеансов, предварительно помеченной неактивностью для всех вызывающим эту команду. Ждём небольшое время (может, не все мгновенно откликнулись), а затем рубим те сеансы, которые остались неактивными.

И этот вариант рассматривал, но не шибко красиво получается... Имеем > 100 активно работающих машин * н-одновременно установленных соединений, эт сколько транзакций в день выйдет?