Kbase P25191: How to handle DataServer connection failures to the third party database in the AppServer
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
03/12/2008 |
|
Status: Verified
GOAL:
How to handle DataServer connection failures to the third party database in the AppServer
GOAL:
What to do if the third party database goes down while AppServer is still connected
FACT(s) (Environment):
MS SQL DataServer
ODBC DataServer
Oracle DataServer
Progress 9.x
OpenEdge 10.x
All Supported Operating Systems
FIX:
As it is not possible to trap the connection failures from the
DataServer to the third party database, all already established
AppServer connections will experience the error condition
upon trying to execute remote procedure on the AppServer.
However, in order to avoid restart of the AppServer and to
provide the meaningful error to the client application when
there is no connection available to the third party database,
it is possible to program the AppServer connect procedure where
it should be always performed the connection on the fly, and depending
on the connection success, provide the client with the connection
or refuse it with the error status.
The AppServer's 'Connect' procedure that uses MS SQL Server as the
third party database should look like this:
DEFINE INPUT PARAMETER User-id AS CHARACTER NO-UNDO.
DEFINE INPUT PARAMETER password AS CHARACTER NO-UNDO.
DEFINE INPUT PARAMETER app-server-info AS CHARACTER NO-UNDO.
IF NOT CONNECTED("schemaHolder") THEN
DO:
CONNECT schemaHolder . /* with all parameters ... */
CONNECT msdatabase -ld "msdb" -dt MSS -U "sa" -P "progress" NO-ERROR.
IF ERROR-STATUS:NUM-MESSAGES > 0 THEN
DO:
MESSAGE ERROR-STATUS:GET-MESSAGE(1) .
RETURN ERROR .
END.
END.
ELSE
DO:
DISCONNECT msdb NO-ERROR.
CONNECT msdatabase -ld "msdb" -dt MSS -U "sa" -P "progress" NO-ERROR.
IF ERROR-STATUS:NUM-MESSAGES > 0 THEN
DO:
MESSAGE ERROR-STATUS:GET-MESSAGE(1) .
RETURN ERROR .
END.
END.
This procedure will return error status on every AppServer connect
if the MS SQL Server database is not reachable for whatever reason.
In the case where the Stateless AppServer is being used, it could
be decided to move this code to the 'Activate' procedure so this code
would be executed on every remote procedure run (and then it wouldn't
need input parameters definitions). However, the connects/disconnects
might represent additional overhead, so it would be required to first
test performance hit in the environment prior to deciding whether
the code would be used in the AppServer's 'Connect' or 'Activate'
entry point.