This section discusses how you can useDB reconnect to reconnect to the same database instance.
The following methods can be used to reconnect to the same database instance:
This is the method used if the SAP internal reconnect mechanism is switched off using the profile parameter
A work process running with an error condition is restarted. This includes a rollback of the SAP logical unit of work (LUW) and a reconnect to the database. If the restart fails, the process terminates. You then have the following options to restart the process:
This type of reconnect is not discussed further in this documentation.
The following diagram illustrates this situation (the work process shown is a dialog process but it might equally well be another kind of process):
DB Reconnect to Same Instance
The reconnect is initiated if a request sent to the database by a work process returns one of the database errors included in the RECONNECT error group. The subsequent processing depends on the type of work process that sent the request.
The advantage of the reconnect without restart of the work process is that it does not require manual intervention. This means that you should never have to restart the whole application server. The application server buffers (that is, the table buffers) are never lost, as would happen during a full server restart. This type of reconnect is also useful if the database was shut down for maintenance or offline backups. Once the database is back up the work processes automatically reconnect.
For this reconnect feature to be active certain parameters have to be set in the application server profile. For more information, see
The following diagram summarizes the reconnect process:
DB Reconnect: Schematic Flow
A work process with a connection problem is changed to "reconnect state," the current SAP LUW is rolled back and the process tries to reconnect. The next steps depend on the type of work process:
The scenario is that user activity generated a synchronous database request (that is, select, insert, modify, delete) that was not successful. The read is rolled back and the dialog process tries to reconnect as follows:
The user receives an "ABAP run-time error" or an error message in the status line of the session screen. The user has to acknowledge the error message. The transaction (LUW) is rolled back and the session returns to the screen from which the aborted transaction was started. The user can now re-run the transaction.
The user’s session screen disappears and a dialog box appears with the message that this session has lost its database connection. The dialog box disappears once it has been acknowledged.
The dialog process that handles the user session screens stays in "reconnect state". Every time a request is passed to the dialog process requiring a database access, it tries to reconnect to the database (for example, if the user repeats the transaction that generated the database request in the first place).
From the dispatcher’s point of view, dialog work processes in reconnect state are no different from other dialog work processes. If a frontend issues a request, the dispatcher might route the request to a dialog work process in reconnect state. This request then causes the next reconnect attempt.
The scenario is that changes have been posted to the database. Asynchronous updates are written by the dialog process to an update queue. An update process reads it from there and applies the changes to the actual database tables. The update queue is implemented as a cluster table (that is,
If the user transaction consists of a sequence of several screens, several data records will have been written toVBLOG . At commit time, a header record is written to VBLOG to complete the information for this change. The set of individual update entries and the single header entry forms one complete update record. The update process applies complete update records only. If a connection error occurred, update entries might have been written, but some update entries or the header entry are still missing. The dialog work process tries to write the missing entries but is not successful. The dialog work process then attempts to reconnect as follows:
Processing is the same as described above for "Foreground Request – Successful Reconnect." That is, the user has to re-run the transaction that was aborted and enter all the data again.
Processing is the same as described above for "Foreground Request – Unsuccessful Reconnect."
The scenario is that an update process wants to read an update record out of the VBLOG, but the read fails due to a database error. The update work process then attempts to reconnect as follows:
The update process tries to read the record again. If other update processes are still connected they might also try to read the record and apply it.
The update process continuously tries to reconnect and apply records that have not been processed yet.
The scenario is that an update process has read an update record and wants to apply it to the actual database tables. The actual update cannot be executed due to a lost connection. The status of this update is "terminated" and the enqueue is released.
If another update process is available, that process is posted to execute the error handling of the terminated update. This process sends an express mail to the user with the message that the update did not complete successfully.
If no other update process is available, the error handling is put in the request queue of the "original" update process.
The next step is the same for a successful as for an unsuccessful reconnect. The update is not repeated automatically and the locks are released. The user has to execute the terminated update again using transaction
The scenario is that an update process wants to do the error handling for a terminated update (that is, send an express mail to the user), but this cannot be done due to a lost database connection. The subsequent processing is independent of whether the reconnect is successful or unsuccessful.
No express mail is sent. The terminated update is shown in transaction
Independent of the outcome of the reconnect, the batch job is terminated. The user then has to restart the batch job, assuming that the application context allows for this.
The spool work process handles user requests to print data. The location of the data to be printed is configurable. It can reside in a table in the database or in external files at the operating system level. In both cases, access to the database is required to process the data.
If a database request for a spool work process fails (that is, either the read of data to be printed or the write of spool administration data), then the spool request is aborted and the user has to start the spool request again. However, the data to be printed is not lost. The spool work process periodically checks for open spool requests.