Что происходит при отключении пользователя

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

При получении клиентским терминалом сигнала завершения работы, такого как SIGHUP, SIGQUIT, SIGTERM и т. д., все пользовательские процессы должны последовательно выполнить следующие действия для корректного выхода из системы:

1. Закрыть все файлы, используемые клиентским сеансом.
2. Записать в лог базы данных информацию о завершении работы пользователя.
3. Блокировать логин-семафор, который используется каждым клиентом для входа в систему и выхода из неё.
4. Удалить информацию о текущем пользовательском процессе из списка активных подключений (usrctl).
5. Освободить и разблокировать логин-семафор.
6. Отключить клиентский процесс от разделяемой памяти (Shared memory).

Эти шаги необходимы для обеспечения корректной идентификации клиентского сеанса в базе данных, так как номер пользователя в OpenEdge не может быть изменён до завершения всех указанных операций. В противном случае, уникальность идентификатора клиента не будет обеспечена, что может привести к ошибкам в управлении доступом.

Особое внимание следует уделить сигналам, генерируемым при завершении работы клиентского сеанса. OpenEdge ожидает сигнал KILL -1, который инициирует процесс очистки всех активных процессов клиентского сеанса и корректного отключения пользователя. В случае получения сигнала KILL -9, который является неконтролируемым сигналом завершения, система не имеет возможности корректно завершить процесс, что может привести к серьёзным последствиям, таким как блокировка входа и выхода из базы данных или даже крах системы.

Особенно критичным является получение сигнала KILL -9 в процессе завершения работы, когда клиентский сеанс удерживает логин-семафор или замок в разделяемой памяти. Это может привести к «зависанию» пользовательского процесса, что в свою очередь вызовет блокировку доступа к базе данных и потенциально приведёт к её аварийному завершению.

В многопользовательском режиме работы с базой данных OpenEdge при подключении пользователя обновляется таблица управления в разделяемой памяти, где фиксируется новый пользователь. В этом процессе происходит захват необходимых ресурсов, включая замки (latches) и блокировки (locks).

Для обеспечения корректного функционирования системы и предотвращения возможных проблем с целостностью данных в OpenEdge предусмотрен механизм проверки активности пользователей. Процесс watchdog (или сервер, если watchdog не задействован) периодически проверяет, что у каждого пользователя, зарегистрированного в таблице управления, есть соответствующий активный процесс. Если обнаруживается, что у пользователя отсутствует активный процесс, он отключается от базы данных, а в лог-файл записывается сообщение о отключении неактивного пользователя (например, «Disconnecting dead user (2527)»).

В случае некорректного завершения процесса пользователя, который удерживал замки или блокировки в разделяемой памяти, база данных может столкнуться с проблемами целостности данных. В лог-файле в таких ситуациях появляются сообщения о том, что пользователь «умер, удерживая замки в разделяемой памяти» (например, «User died holding shared memory locks (2522)») или «умер с заблокированными буферами» (например, «User died with buffers locked (2523)»).

Для предотвращения искажений данных в случае некорректного завершения работы базы данных сервер инициирует аварийное завершение (ABNORMAL shutdown). В лог-файл записывается соответствующее сообщение с кодом ошибки (например, «Begin ABNORMAL shutdown code x (2249)»), которое указывает на необходимость последующего восстановления данных. После перезапуска сервера механизм восстановления (crash recovery) активируется, и база данных становится доступной для дальнейшей работы.

Во время аварийного завершения работы в лог-файле также могут появляться сообщения о системных ошибках, таких как «System Error: redundant lwake user <n> latch <x>». Эти сообщения не свидетельствуют о нарушении целостности данных и являются следствием аварийного завершения работы системы.

Основные причины некорректного завершения процессов пользователей включают:

1. Отправка процессу сигналов завершения, кроме сигнала SIGHUP.
2. Отключение терминала во время активного сеанса OpenEdge. Если терминал отправляет сигнал SIGHUP, когда сеанс неактивен, проблем не возникает.
3. Системные ошибки, приводящие к аварийному завершению процесса.

Для повышения эффективности использования сигналов в системе OpenEdge была проведена оптимизация их обработки. Подробная информация о сигнальной обработке в OpenEdge доступна в базе знаний ProKB.

В случае многократного возникновения ошибок, связанных с аварийным завершением пользовательских процессов, необходимо провести анализ причин таких сбоев. Один из методов предотвращения аварийного завершения процессов — запуск пользователей в режиме удалённых клиентов (remote clients). В этом режиме пользователи не имеют прямого доступа к разделяемой памяти. Вместо этого они взаимодействуют с сервером через клиентское соединение, который осуществляет доступ к разделяемой памяти и управляет замками буфера (buffer latches) для пользовательского процесса. В случае некорректного завершения пользовательского процесса, серверный процесс продолжит работу и сможет освободить все занятые ресурсы, включая оставшиеся замки.

Примеры запуска сервера и клиентского сеанса в режиме удалённого клиента:

1. Запуск сервера с сетевыми параметрами:

proserve db-name -S <portnumber> -H <host name>

2. Запуск пользовательского сеанса как локального удалённого клиента на той же машине:

mpro db-name -S <port number> -H <host name>

Следует отметить, что производительность соединений через разделяемую память и по сети (TCP) может различаться. Традиционно доступ через разделяемую память демонстрирует более высокую скорость, так как не требует передачи данных по протоколу TCP. Однако начиная с версии OpenEdge 12.2, производительность сетевых подключений была значительно улучшена, что сокращает разрыв в скорости между этими двумя типами соединений.