In this section: |
COMMIT and ROLLBACK improve SU performance because the ability to group individual transactions as one logical transaction requires fewer disk I/Os. Reducing the number of individual transactions also reduces the number of communications between the sink machine and source user IDs. Specifically, only one communication takes place when transactions are rolled back, and no communication occurs when a record is matched a second time. Both of these situations are common with multi-record processing.
When using CHECK processing, the sink machine buffers all changes to BINS before saving your changes to the database. The changes are saved from BINS to disk when a checkpoint is issued using the CHECK command in MODIFY. For example, CHECK 5 tells the MODIFY procedure to issue a checkpoint after every five changes to the database.
The CHECK facility has several limitations. There is little control over when checkpoints are invoked. When one user on a sink machine issues a checkpoint, the sink saves all other users' changes. Also, changes cannot be undone.
The use of COMMIT and ROLLBACK provides a number of advantages over the CHECK facility. All changes are held by the source machine until a COMMIT is issued, and then the changes are sent to the sink. No one else sees your changes until you issue a COMMIT. The changes can be cancelled by the ROLLBACK command.
COMMIT and ROLLBACK are controlled by the MODIFY or Maintain procedure and are not subject to the checkpoints of other users. All or nothing processing is guaranteed, even upon system failure. Because all the changes are sent to the sink machine in one message, processing is more efficient.
FOCURRENT logic is necessary for determining whether or not transactions have been accepted. In an application without COMMIT and ROLLBACK, FOCURRENT cannot deal with multiple changes and may be difficult to implement.
When you use COMMIT and ROLLBACK, you should test FOCURRENT after each COMMIT. If the COMMIT fails, FOCURRENT is set to a non-zero value. MODIFY or Maintain only checks FOCURRENT after a COMMIT, not after every transaction. If the value of FOCURRENT is not zero, MODIFY or Maintain rolls back the entire logical transaction.
Note also that if FOCURRENT has a non-zero value, no message is issued. Therefore, you should test FOCURRENT explicitly after a COMMIT and take any appropriate action; otherwise no message is displayed and processing returns to the top case.
Changes by other users can be seen only after a COMMIT has been issued and processed successfully. If you MATCH or NEXT on a record more than once and you have not issued a COMMIT, the MODIFY or Maintain does not go to the sink again. This means that you will not see other users' changes until your MODIFY or Maintain executes a COMMIT command, although you will see your own changes. Once a COMMIT is performed, the record will come from the database if you MATCH or NEXT on it.
This concept is especially important when the MODIFY or Maintain uses FIND or LOOKUP. These operations cause records to be retrieved from the sink database. FIND and LOOKUP do not search for values on the local copies of the records. For example, if you have included a record and then use LOOKUP to obtain a value on this record, the value will not be found if you have not issued a COMMIT.
| Information Builders |