Kbase 17918: What a Progress user does during the logout process
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
9/24/2008 |
|
Status: Verified
GOAL:
What a Progress user does during the logout process
GOAL:
What happens during a client logout process
FACT(s) (Environment):
All Supported Operating Systems
Progress/OpenEdge Versions
FIX:
When a user logs out of a database, the user process goes through an internal routine that cannot be interrupted if a valid logout message is to be reported.
The routine described within this solution attempts to explain what happens during a client logout process.
The following, is a sequence of events that all client sessions perform when gracefully exiting a Progress database. The term graceful infers that the client connection has sent the proper signal that Progress database broker expects (i.e. SIGHUP, SIGQUIT, SIGTERM, etc...).
1) Close all files the client session currently has open.
2) Write a log out message to the Progress database log (DBname.lg).
3) Lock the login semaphore. (This is the semaphore which every client logging in to and out of the database must posses in order to enter/exit the database.
4) The client session must then remove themselves from the usrctl slot. (This is the list of current active and batch connections to the database).
5) Release/Unlock the login semaphore.
6) Disconnect from shared memory.
The reason why the client session must follow this routine every time has to do with the Progress assigned user number. Basically, a client session's user number cannot be reassigned until they complete all the steps in this process. If this were not the case then we wouldn't have a unique number by which to identify a client session within the database log.
Now to elaborate a little more on the signal issue. Progress expects a -1 to be sent when a client session sends a hang-up signal so we can clean up after the client session's processes and gracefully disconnect the client session from the database.
When we receive a signal we cannot trap, such as a KILL -9, we have no way to track the client session.
Receiving a KILL -9 during the routine described earlier can have catastrophic consequences. An example would be the client session holding the login semaphore being sent the untrapable signal. This would cause the user to die holding the semaphore, thus nobody else would be able to log in or out of the database. This issue could further cloud things if the user was killed by an untrapable signal before the routine reached step 6 "Disconnect from shared memory". If this happened and the client session in question was holding a latch in shared memory, this would bring the database down. For more details, see solution P36402, "Why a Database shutdowns with the message User died holding shared memory lock?" .