Kbase P13584: What does Progress do during the logout process?
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
6/7/2008 |
|
Status: Unverified
FIX:
What does Progress do during logout process?
When a typical user logs out of a database, it goes through an
internal process that cannot be interrupted if a valid logout message
is to be reported. We often talk about Progress getting a hang-up
signal if we are going to disconnect the user properly, and the process
outlined in this article will shed some light on that issue as well.
The following is a list of events that all users gracefully exiting
the database should go through. Graceful here means that the user has
sent the proper signal that Progress is expecting SIGHUP, SIGQUIT,
SIGTERM, etc.
1) Close all files the user currently has open.
2) Write a log out message to the Progress log file (dbname.lg).
3) Lock the login semaphore. This is the semaphore which every user
logging into and out of the database must have locked in order to
enter/exit the database.
* This will be discussed in detail when we discuss untrappable
signals effect on this process.
4) The user must then remove themself 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 this process must follow this sequence of events every
time has to do with the user number. Basically a user'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 user in the database log file. Imagine
how confusing that would be.
Now to elaborate a little more on the signal issue. Progress expects
a -1 to be sent when a user sends a hang-up signal so we can clean up
after the user processes and gracefully disconnect them from the
database. When we receive a signal we cannot trap, like a kill -9, we
have no way to track the process.
Receiving a kill -9 during the process outlined earlier in the article
can have catastrophic consequences. An example would be the user
holding the login semaphore being sent the untrappable 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 gets killed by an untrappable signal
before they get to step 6) Disconnect from shared memory. If this
happens and the user in question is holding a latch in shared memory,
this will bring the database down unconditionally.
The error that would usually be associated with the user in this case would be the following:
SYSTEM ERROR: Releasing regular latch.
latchId:<latch-num> (5028)
User <num> died holding <num> shared memory locks. (5026)
User <num> died with <num> buffers locked. (5027)
SYSTEM ERROR: Releasing multiplexed latch. latchId:<latch-num> (5029)