Run Units, Locks, and Database Transactions › Database Transactions

Database Transactions

A database transaction is a unit of recovery that represents work done by one or more database sessions. All access to CA IDMS data from within a run unit is done under the control of a database transaction.

Journaling Changes

Every time your program modifies the database, a before and after image of the affected record occurrence is written to the journal file. These images are used in the event of program or system failure to recover (roll back) all changes made to the database. During a rollback, updates are reversed to the last checkpoint written to the journal file.

Checkpoints

Checkpoints are written at the following times:

• When a database transaction is started or when the first update is made. For run units that don't share their transaction, its transaction starts when a BIND RUN-UNIT is issued.
• When a database transaction is committed. For run units that don't share their transaction, this occurs when a FINISH or COMMIT request is issued.
• When a database transaction is backed out. For run units that don't share their transaction, this occurs when a ROLLBACK request is issued.

A database transaction encompasses the work done between two checkpoints. A database transaction is also a recovery unit since all changes made by a transaction are committed or recovered as a single unit.

Note: If a database transaction is shared by more than one session, itimpacts when checkpoint records are written.

For more information, see Sharing Transactions Among Sessions.

Automatic Recovery Under Central Version

Recovery takes place automatically for programs running under the central version. In order to recover under local mode, you must manually recover the database by using CA IDMS recovery utilities or by restoring the database files from a backup copy.

For more information on recovering the database under local mode, see the CA IDMS Database Administration Guide.

Rolling Back the Database

The figure below shows journaling, checkpoints, and rollback. The BIND RUN-UNIT statement writes the initial checkpoint to the journal file. Before and after images are maintained for every modified record occurrence. In the event of an abend, the central version uses the before images to restore the database back to the last checkpoint. In this figure, there is a one-to-one association between the run unit and its database transaction.

Establishing Checkpoints

The figure below shows the use of the COMMIT statement to establish checkpoints. In the event of an abend, the central version restores the database as far back as the last COMMIT checkpoint.

Committing Changes

If your application performs database updates, you should commit those updates at regular intervals to:

• Release implicit locks held by the database transaction
• Prevent needless rollback of valid database updates

Frequency of COMMIT Statements

Since modified records are implicitly and exclusively locked, timely use of the COMMIT statement is an important programming consideration.

The frequency of issuing COMMITs is a site- and application-specific decision. Some questions to ask when determining the frequency of COMMITs are:

• Is a logical unit of work complete?-You should maintain implicit exclusive locks at least until a logical unit of work is complete. For example, if you plan to DISCONNECT and subsequently CONNECT a record, you should not issue the COMMIT until after the CONNECT.
• What is the application's operating environment?-If there will be a high volume of concurrent online users, you should try to keep database transactions short by issuing COMMITs more frequently.
• How many locks will be held for each record modified?-:ih1.locks Additional implicit exclusive record locks (for example, on the NEXT and PRIOR records) are held when modifying symbolic keys, when erasing occurrences from the database, when connecting or disconnecting records, or when modifying variable-length records.

  For detailed information on the implicit exclusive record locks maintained for each modified record, see Implicit Record Locks.

• How many locks is too many?-This is application- and site-specific, although you probably do not want to maintain implicit exclusive locks on more than 70-100 records at any one time.

  Note: You can use the IDMS statistics block (explained in Collecting Database Statistics) to obtain lock-related information at run time.