Kbase P32756: Database not connected (1006) with state-reset app server
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
4/18/2008 |
|
Status: Unverified
FACT(s) (Environment):
Progress 9.1x
SYMPTOM(s):
Database <db> not connected (1006)
State-reset server failed to reconnect to database <name>. (7980)
State-reset app servers error out with above error messages
Database down without app server shut down
The appserver is connected to the database via shared memory
Restarting the database will not immediately stop these messages from the appserver.
Would like to trap and handle the errors in connect procedure gracefully
CAUSE:
When an AppServer is in state-reset mode, it will "reset" itself for each client connection.
More correctly, it will reset itself when a client disconnects itself from the appserver. The reset process will return the AppServer to the state it was in when it was first started. This includes connecting to any databases that were connected from the AppServer startup parameters (effectively using the startup parameters to reconnect to the database).
The following are what happens when a database shuts down while the appserver is still connected to it.
If the appserver is connected self-service to the database, the appserver will know that the database has been disconnected, but it will still be available to receive client connections. When the client connects and tries to run a program, the appserver will provide an error, typically "Database <db> not connected (1006)", or a syntax error if the code is not compiled.
In both these situations, once the client disconnects from the appserver, the appserver will reset itself. This includes trying to reconnect to the database that is down.
If the database is still down, the appserver will fail to connect to it. At this point, the following message will be displayed in the .server.log file:
State-reset server failed to reconnect to database <name>. (7980) The appserver will then make itself available to handle more client connections.
On the next client connection, regardless of whether the db connection is client/server or self-service, the appserver will fail to run a program, giving the (1006) error again.
Again, once the client disconnects, the appserver will reset itself. These (1006) and (7980) errors will continue until the database is restarted, or the appserver is stopped.
Restarting the database will not immediately stop these messages from the appserver. The appservers have already been reset at that time, and have failed to connect to the database. The only way to make the connect in this case is to have clients connect to the appservers then disconnect again, which resets the appserver again. The appserver will then be able to connect to the database. This means that once the database has been restarted, each appserver must have a single client connection (with the (1006) message) before it can reconnect to
the database and resume normal processing.
These messages might cause the users some concern, and good program dictates that they should be trapped and handled gracefully. The suggested method to do this is to use the connect procedure. This is discussed in the "Building Distributed Applications" manual. The connect procedure is run by the appserver on each client connection, before processing any programs for the client. In this procedure, you can use the 4GL to check if the appserver is connected to the
database. If not, you can use RETURN ERROR to deny connection to the client process. The client code can then trap this connection failure, and handle it gracefully.
An alternative to the above connect method is if the database is not connected, try to connect to it from the 4GL (with a NO-ERROR), then check again if it is not connected. This will eliminate the one cycle of appservers required when the db is first brought up. The disadvantages of this are that the client connection will take longer to process when the db is down (has to wait for the db connection to time out), and the db connection parameters will be hard-coded.
FIX:
The suggested method to do this is to use the connect procedure. The connect procedure is run by the appserver on each client connection, before processing any programs for the client. In this procedure, you can use the 4GL to check if the appserver is connected to the database. If not, you can use RETURN ERROR to deny connection to the client process. The client code can then trap this connection failure, and handle it gracefully.
If the database is not connected, try to connect to it from the 4GL (with a NO-ERROR), then check again if it is not connected.