Rollback operation

 

A rollback operation removes all changes made since the previous commit or rollback operation. The system also releases all locks related to the transaction.

The system performs the following steps when it receives a request to roll back:

• The system clears records from the I/O buffer if both of the following conditions are true:

  • If records were added to a local or remote database file under commitment control.

  • If SEQONLY(*YES) was specified when the file was opened so that blocked I/O is used by the system and a partial block of records exists that has not yet been written to the database.

  Otherwise, the I/O feedback area and I/O buffers remain unchanged.

• The system makes a call to the commit or rollback exit program for each API commitment resource that is present in the commitment definition. If a location has more than one exit program registered, the system calls the exit programs for that location in reverse order from the order in which they were registered.

• If a record was deleted from a file, the system adds the record back to the file.

• The system removes any changes to records that have been made during this transaction, and places the original records (the before-images) back into the file.

• If any records were added to the file during this transaction, they remain in the file as deleted records.

• If any record changes were made to resources assigned to a journal during the transaction, the system adds a journal entry of C RB to the journal, indicating that a rollback operation occurred. The journal also contains images of the record changes that were rolled back. Before the rollback operation was requested, the before-images and after-images of changed records were placed in the journal. The system also writes C RB entry to the default journal if any committable resources are assigned to that journal.

• The system positions the open files under commitment control at one of the following positions:

  • The last record accessed in the previous transaction

  • At the open position if no commit operation has been performed for the file using this commitment definition
  This consideration is important if you are doing sequential processing.

• The system does not roll back noncommittable changes for database files. For example, opened files are not closed, and cleared files are not restored. The system does not reopen or reposition any files that were closed during this transaction.

• The system unlocks record locks that were acquired for commitment control purposes and makes those records available to other users.

• The commit identification currently saved by the system remains the same as the commit identification provided with the last commit operation for the same commitment definition.

• The system reverses or rolls back object-level committable changes made during this transaction.

• Object locks that were acquired for commitment control purposes are unlocked and those objects are made available to other users.

• The system establishes the previous commitment boundary as the current commitment boundary.

• The system changes information in the commitment definition to show that the current transaction has been ended.

The system must perform all of the previous steps correctly for the rollback operation to be successful.

 

Parent topic:

How commit and rollback operations work