 |
Qorus Integration Engine®
4.0.3.p2_git
|
|
Qorus Integration Engine®
4.0.3.p2_git
|
Qorus Integration Engine® application sessions should not to be confused with database sessions. Conceptually, an application session corresponds to an instance of Qorus Integration Engine® that is (or was) running on an Qorus database schema, and directly corresponds to a row in the SESSIONS table in the Qorus system schema. The Qorus instance is identified by its instance key, normally set in the System Options File.
When Qorus starts without the qorus.auto-recover option set, it checks the SESSIONS table for a row with an ACTIVE status with the same instance key. If such a session is found, then an error message is displayed and the system will not start, as it is illegal for the same instance to have more than one active session in the same Qorus database.
This rule is designed to allow for session recovery in the case of system failures, while still allowing for concurrent Qorus instances to access the same database.
Otherwise, if no ACTIVE row in the SESSIONS table for the current instance is found, a new row is created with the current session ID and the status is set to ACTIVE.
In the case of a system failure, such as a system crash, a session will normally be left open (status still set to ACTIVE) even though the Qorus process is no longer running. In this case, the Qorus process must be started with the qorus.auto-recover option set to True.
With this option turned on, the Qorus process will try to contact the instance using the URL given in the SESSIONS.XMLRPC_SERVER field. If the server can be contacted, then the process assumes that the Qorus server is still running, and refuses to start again, exiting with an error message. Otherwise system recovery takes place with the following recovery actions.
The session recovery procedures (SQL select/update statements) are split into batches due the performance reasons. It means that all steps described below are performend 1..N times depending on amount of data in the system database schema.
Size of these batches can be set by options:
Step 1: Set IN-PROGRESS Step Instance Statuses to RETRY
Any step instances with status OMQ::StatInProgress that belong to a workflow instance marked with the failed session's session ID will have the step instance status set to OMQ::StatRetry.
Step 2: Set IN-PROGRESS Segment Instance Status to RETRY
Any segment instances with status OMQ::StatInProgress that belong to a workflow instance marked with the failed session's session ID will have the segment instance status set to OMQ::StatRetry.
Step 3: Set IN-PROGRESS Workflow Instance Status to RETRY
Any workflow instances with status OMQ::StatInProgress that are also tagged with the failed session's session ID will have the workflow instance status set to OMQ::StatRetry.
Step 4: Clear Old Session ID From Workflow Instances
Any remaining workflows marked with the old session's ID will have the session ID column cleared.
All of the above actions are logged.