Scenario: Commitment control

The JKL Toy Company uses commitment control to protect the database records for manufacturing and inventory. This scenario shows how JKL toy company uses commitment control to transfer a part from its inventory department to its manufacturing department.

The Scenario: Journal management topic includes a description of JKL Toy Company's network environment. The scenario that follows shows how commitment control works on its production system JKLPROD.

This scenario illustrates the advantages of using commitment control in two examples. The first example shows how the company's inventory program, Program A, might work without commitment control, and the possible problems that can occur. The second example shows how the program works with commitment control.

The JKL Toy Company uses an inventory application program, Program A, on its system JKLPROD. Program A uses two records. One record tracks items that are stored in the stock room. Another record keeps track of items that are removed from the stock room, and used in production.

Program A without commitment control

Assume that the following application program does not use commitment control. The system locks records read for updating. The following steps describe how the application program tracks a diode as it is removed from the stock room and transferred to checking account:

Program A locks and retrieves the stock room record. (This action might require a wait if the record is locked by another program.)
Program A locks and retrieves the production record. (This might also require a wait.) Program A now has both records locked, and no other program can change them.
Program A updates the stock room record. This causes the record to be released so it is now available to be read for update by any other program.
Program A updates the production record. This causes the record to be released so it is now available to be read for update by any other program.

Without using commitment control, a problem needs to be solved to make this program work properly in all circumstances. For example, a problem occurs if program A does not update both records because of a job or system failure. In this case, the two files are not consistent -- diodes are removed from the stock room record, but they are not added to the production record. Using commitment control allows you to ensure that all changes involved in the transaction are completed, or that the files are returned to their original state if the processing of the transaction is interrupted.

Program A with commitment control

If commitment control is used, the preceding example is changed as follows:

Commitment control is started.
Program A locks and retrieves the stock room record. (This action can require a wait if the record is locked by another program.)
Program A locks and retrieves the production record. (This can also require a wait.) Program A now has both records locked, and no other program can change them.
Program A updates the stock room record, and commitment control keeps the lock on the record.
Program A updates the production record, and commitment control keeps the lock on the record.
Program A commits the transaction. The changes to the stock room record and the production record are made permanent in the files. The changes are recorded in the journal, which assumes they will appear on disk. Commitment control releases the locks on both records. The records are now available to be read for update by any other program.

Because the locks on both records are kept by commitment control until the transaction is committed, a situation cannot arise in which one record is updated and the other is not. If a routing step or system failure occurs before the transaction is committed, the system removes (rolls back) the changes that have been made so that the files are updated to the point where the last transaction was committed.

For each routing step in which files are to be under commitment control, the steps shown in the following figure occur:

The operations that are performed under commitment control are journaled to the journal. The start commitment control journal entry appears after the first file open entry under commitment control. This is because the first file open entry determines what journal is used for commitment control. The journal entry from the first open operation is then used to check subsequent open operations to ensure that all files are using the same journal.

When a job failure or system failure occurs, the resources under commitment control are updated to a commitment boundary. If a transaction is started but is not completed before a routing step ends, that transaction is rolled back by the system and does not appear in the file after the routing step ends. If the system abnormally ends before a transaction is completed, that transaction is rolled back by the system and does not appear in the file after a subsequent successful initial program load (IPL) of licensed internal code. Anytime a rollback occurs, reversing entries are placed in the journal.

For example, assume that JKL company has 100 diodes in stock. Manufacturing takes out 20 from stock, for a new balance of 80. The database update causes both before-image (100) and after-image (80) journal entries.

Assume the system abnormally ended after journaling the entries, but before reaching the commitment point or rollback point. After the IPL, the system reads the journal entry and updates the corresponding database record. This update produces two journal entries that reverse the update: the first entry is the before-image (80) and the second entry is the after-image (100).

When the IPL is successfully completed after the abnormal end, the system removes (or rolls back) any database changes that are not committed. In the preceding example, the system removes the changes from the stock room record because a commit operation is not in the journal for that transaction. In this case, the before-image of the stock room record is placed in the file. The journal contains the rolled back changes, and an indication that a rollback operation occurred.