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 FOCUS Database server 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 FOCUS Database server 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 FOCUS Database Server issues a checkpoint, the server saves pending changes from all other users. Also, changes cannot be undone.
COMMIT and ROLLBACK provide a number of advantages over the CHECK facility. The source machine holds all pending changes until a COMMIT is issued, and then the changes are sent to the server. 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 changes are sent to the FOCUS data source 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 and Maintain only check 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 are only visible after a COMMIT has been issued and processed successfully. If you issue a MATCH or NEXT command on a record more than once and you have not issued a COMMIT, the MODIFY or Maintain does not go to the server again. This means that you will not see changes made by other users 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 issue a 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 central 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 |