IBM i General Design Standards › Design Standards for Programs › Record Locking

Record Locking

Always make allowance for the possibility of records being inaccessible due to locks by another job. In RPG III, this should normally consist of testing the result indicator (col 56-57) on file access operations. The appropriate action to take will depend upon the context.

For single record updates in interactive programs, it will normally be sufficient to abandon the update and report a ‘record in use’ error message.

For multiple record updates in interactive programs, and all batch updates, you will either need to rollback and report a ‘record in use’ error message, or carry out whatever partial update is still feasible. In the latter case, you must be able to report back what has, and what has not, been updated.

Note that file design may be used to reduce multiple record updates to what are effectively single record updates. Potential lock situations can usually be designed out of an application. For instance, if an invoice maintenance program requires a lock on the invoice header before it will allow editing of invoice details, it will probably not be necessary to check for locks on the invoice detail records.

There are two basic strategies that can be adopted with regard to the locking of data records:

• Pre-allocation: A record that is to be updated is locked before the data to update the record is processed. The lock is held until the update is completed. This method allows for simple programming and may be appropriate for interactive programs, when the files that are being updated are not required for update by other processes at the same time.
• Rollback: A record that is to be updated is locked only for the instant of update. This generally removes problems of contention. However, it requires an extra database read, and if the update is being done on the basis of existing record values, it will usually require programming to check that a record has not been altered by another process between the initial access and the actual update. If such an update has taken place, it will be necessary to report the error, and it may be necessary to execute a rollback to undo any associated updates that have already been completed on the premise that a record could be updated (for example, update of a batch header before update batch records).