Previous Topic Next topic Print topic


Rolling Back a Transaction

Restriction: This topic applies to Windows environments only.

Sometimes an unacceptable condition is detected by a user or by the system after some changes have been made to the data. Additionally, two or more concurrently executing transactions could enter into a deadlock waiting for each other to release locked objects, and the system may force one of the transactions to abort. In all cases, all changes made to the data by an aborted transaction must be reversed in order to maintain the data in a consistent state. If the system detects a problem that requires the transaction to abort, it automatically reverses all the changes made to the data by the transaction. If the transaction decides to abort itself, it is the responsibility of the transaction to request a rollback of all changes it made to the data.

When a transaction is to be aborted, all of the changes made to the data during the current transaction must be undone. The ROLLBACK command is provided for this purpose. The effect of ROLLBACK is to undo all of the changes made to the data since the transaction began. Starting the server after a system failure triggers an automatic ROLLBACK of any incomplete transaction.

Note:

The XDB Server does not roll back or recover the Data Control Language (DCL) commands such as GRANT and REVOKE; or utility commands such as SET and DROP TABLE. When working in a production environment, it is recommended that you back up your location before and after such commands.

A program may contain multiple transactions. The first transaction begins when the program starts, and ends with either a ROLLBACK or COMMIT command. Subsequent transactions begin with the last COMMIT or ROLLBACK command, and end with the next COMMIT or ROLLBACK command.

Previous Topic Next topic Print topic