Journaled files and commitment control

 

You must journal (log) a database file (resource type FILE or DDM) before it can be opened for output under commitment control or referenced by an SQL application that uses an isolation level other than No Commit. A file does not need to be journaled in order to open it for input only under commitment control.

An error occurs if any of the following conditions is true:

If only the after-images are being journaled for a database file when that file is opened under commitment control, the system automatically starts journaling both the before-images and after-images. The before-images are written only for changes to the file that occur under commitment control. If other changes that are not under commitment control occur to the file at the same time, only after-images are written for those changes.

The system automatically writes record-level committable changes and object-level committable changes to a journal. For record-level changes, the system then uses the journal entries, if necessary, for recovery purposes; the system does not use entries from object-level committable changes for recovery purposes. Furthermore, the system does not automatically write journal entries for API commitment resources. However, the exit program for the API resource can use the Send Journal Entry (QJOSJRNE) API to write journal entries to provide an audit trail or to assist with recovery. The content of these entries is controlled by the user exit program.

The system uses a technique other than a journal to perform recovery for object-level commitment resources. Recovery for API commitment resources is accomplished by calling the commit and rollback exit program associated with each particular API commitment resource. The exit program has the responsibility for performing the actual recovery that is necessary for the situation.

 

Parent topic:

How commitment control works with objects

 

Related concepts


Journal management