Отслеживание текущих соединений пользователей
Отслеживание текущих соединений пользователей
День добрый. Столкнулся с проблемой следующего содержания - Есть база, к ней подключаются n-ное количество пользователей, причем один и тот-же пользователь может использовать несколько подключений к базе. А теперь собственно вопрос, как можно проконтролировать что какое-либо соединение еще активно? В теории можно воспользоваться TMP$ATTACHMENTS, но так-как соединений у пользователя может быть больше одного, то не совсем понятно как его отследить. Можно использовать дотолнительную таблицу для хранении информации о входе/выходе, но в случае аварийного завершения работы приложения опять-же не поможет... Мож кто сталкивался. Буду благодарен за совет...
тогда никак. вопрос об идентификации приложения, установившего соединение с сервером, уже возникал, но это невозможно - коннекты для сервера отличаются только именем пользователя и ip.В теории можно воспользоваться TMP$ATTACHMENTS, но так-как соединений у пользователя может быть больше одного, то не совсем понятно как его отследить.
Первая глупая идея такова:
Пусть приложение при запуске берёт себе session_id из какого-нибудь специально для этого генератора. И все вызовы процедур выполняет с передачей этого session_id. А напрямую из приложения таблицы не редактировать - пусть этим процедуры занимаются. Таким образом, сервер знает, кто выполняет конкретное действие.
Конечно, тут нужно во всех процедурах этот параметр вводить...
Пусть приложение при запуске берёт себе session_id из какого-нибудь специально для этого генератора. И все вызовы процедур выполняет с передачей этого session_id. А напрямую из приложения таблицы не редактировать - пусть этим процедуры занимаются. Таким образом, сервер знает, кто выполняет конкретное действие.
Конечно, тут нужно во всех процедурах этот параметр вводить...
Если пользоваться твоим определением - все коннекты всегда являются активными.MrAndrew писал(а):Значится, что соединение с базой установленно, и не прервано. Для чего? Чтоб снять все блокировки с записей и таблиц, коии могут редактироваться только монопольльно + ведение лога + и еще много чего полезного
Тогда при чём тут существующие соединения? Чего-то не догоняю.
Или ты хочешь на сервере прибить соединения, которые не имеют клиента? Тогда это возможно - такие соединения не имеют открытого сокета. Реализация нахождения зависит от платформы. Для Linux - для каждого из gds_inet_server смотрим pid процесса, по pid смотрим открыто ли соединение 3050/tcp или где там у тебя, если не нашли - можно прибивать.
Или ты хочешь на сервере прибить соединения, которые не имеют клиента? Тогда это возможно - такие соединения не имеют открытого сокета. Реализация нахождения зависит от платформы. Для Linux - для каждого из gds_inet_server смотрим pid процесса, по pid смотрим открыто ли соединение 3050/tcp или где там у тебя, если не нашли - можно прибивать.
-
- Заслуженный разработчик
- Сообщения: 1436
- Зарегистрирован: 15 сен 2005, 09:05
WildSery: Не получиться... Тут судя по всему виновато не совсем точное описание проблемы. Попробую еще раз:
Есть пользователь подключившийся к базе н-раз, при установке соединения он регистрируется в таблице CONNECTED, то есть через генератор код соединения получен, далее ему необходимо изменить запись в таблице, работа с которой, по бизнес-логике возможна только монопольно. Для этого использую метод а-ля 1с то есть через свою таблицу блокировок, (объект, запись, код соединения, флаг блокировки)
После блокировки пользователь благополучно отваливается, соответственно запись более никто изменить не может. Для решения возникшего вопроса требуется отследить а живой ли он еще, ежли нет, то снять блокировку.
Есть таблица текущих соединений TMP$ATTACHMENT содержащая необходимую информацию, и в теории можно было бы взять значение поля TMP$ATTACHMENT_ID для привязки, но, так как соединений у пользователя больше одного, то как его тогда найти, родимого, в этом компоте?, или обойти этот вопрос как-то иначе
Есть пользователь подключившийся к базе н-раз, при установке соединения он регистрируется в таблице CONNECTED, то есть через генератор код соединения получен, далее ему необходимо изменить запись в таблице, работа с которой, по бизнес-логике возможна только монопольно. Для этого использую метод а-ля 1с то есть через свою таблицу блокировок, (объект, запись, код соединения, флаг блокировки)
После блокировки пользователь благополучно отваливается, соответственно запись более никто изменить не может. Для решения возникшего вопроса требуется отследить а живой ли он еще, ежли нет, то снять блокировку.
Есть таблица текущих соединений TMP$ATTACHMENT содержащая необходимую информацию, и в теории можно было бы взять значение поля TMP$ATTACHMENT_ID для привязки, но, так как соединений у пользователя больше одного, то как его тогда найти, родимого, в этом компоте?, или обойти этот вопрос как-то иначе
-
- Заслуженный разработчик
- Сообщения: 1436
- Зарегистрирован: 15 сен 2005, 09:05
Oops... Извини, не обратил внимания что у тебя перечислены процессы gds_inet_server. Почему-то подумалось что при локальном соединении (именно через него работают сервисы) они тоже возникают, а там ведь всего лишь сошка загружается в процессы с совсем другими именами.WildSery писал(а):Если процесс висит, а клиента нет - каким образом я могу кого-то угрохать? Приведи пример.
Пусть все клиентские приложения по команде (например, event) сообщают о своей активности, ставя флаг в табличке сеансов, предварительно помеченной неактивностью для всех вызывающим эту команду. Ждём небольшое время (может, не все мгновенно откликнулись), а затем рубим те сеансы, которые остались неактивными.
-
- Заслуженный разработчик
- Сообщения: 1436
- Зарегистрирован: 15 сен 2005, 09:05
А не пойти бы тебе почитать это?..MrAndrew писал(а):Соответственно при помощи удаления записи из нее я автоматом убираю все текущие блокировки пользователя.
Был, читал особенно понравилось - Основной минус тут один: запись может висеть в заблокированном состоянии сколько угодно, поэтому желательно наличие какого-нибудь администратора, который может принудительно разблокировать любую запись.Dimitry Sibiryakov писал(а):А не пойти бы тебе почитать это?..MrAndrew писал(а):Соответственно при помощи удаления записи из нее я автоматом убираю все текущие блокировки пользователя.
Так где здесь лекарство, может я просмотрел невнимательно?
И этот вариант рассматривал, но не шибко красиво получается... Имеем > 100 активно работающих машин * н-одновременно установленных соединений, эт сколько транзакций в день выйдет?WildSery писал(а):Пусть все клиентские приложения по команде (например, event) сообщают о своей активности, ставя флаг в табличке сеансов, предварительно помеченной неактивностью для всех вызывающим эту команду. Ждём небольшое время (может, не все мгновенно откликнулись), а затем рубим те сеансы, которые остались неактивными.