Minimizing locks
A typical way to minimize record locks is to release the record lock. (This technique does not work if LCKLVL(*ALL) has been specified.)
Here is an example of minimizing record locks by releasing the record lock. A single file maintenance application typically follows these steps:
- Display a prompt for a record identification to be changed.
- Retrieve the requested record.
- Display the record.
- Allow the workstation user to make the change.
- Update the record.
In most cases, the record is locked from the access of the requested record through the update. The record wait time might be exceeded for another job that is waiting for the record. To avoid locking a record while the workstation user is considering a change, release the record after it is retrieved from the database (before the record display appears). You then need to access the record again before updating. If the record was changed between the time it was released and the time it was accessed again, inform the workstation user. The program can determine if the record was changed by saving one or more fields of the original record and comparing them to the fields in the same record after it is retrieved as follows:
- Use an update count field in the record and add 1 to the field just before an update. The program saves the original value and compares it to the value in the field when the record is retrieved again. If a change has occurred, the workstation user is informed and the record appears again. The update count field is changed only if an update occurs. The record is released while the workstation user is considering a change. If you use this technique, use it in every program that updates the file.
- Save the contents of the entire data record and compare it to the record the next time it is retrieved.
In both of the previous cases, the sequence of operations prevents the simple use of externally described data in RPG where the same field names are used in the master record and in the display file. Using the same field names (in RPG) does not work because the workstation user's changes are overlaid when the record is retrieved again.You can solve this problem by moving the record data to a data structure. Or, if you use the DDS keyword RTNDTA, you can continue to use externally described data. The RTNDTA keyword allows your program to reread data on the display without the operating system having to move data from the display to the program. This allows the program to perform the following tasks:
- Prompt for the record identification.
- Retrieve the requested record from the database.
- Release the record.
- Save the field or fields used to determine if the record was changed.
- Display the record and wait for the workstation user to respond.
If the workstation user changes the record on the display, the program uses the following sequence:
- Retrieve the record from the database again.
- Compare the saved fields to determine if the database record has been changed. If it has been changed, the program releases the record and sends a message when the record appears.
- Retrieve the record from the display by running a read operation with the RTNDTA keyword and updates the record in the database record.
- Proceed to the next logical prompt because there are no additional records to be released if the workstation user cancels the request.
LCKLVL(*CHG) and LCKLVL(*CS) work in this situation. If LCKLVL(*ALL) is used, release the record lock by using a commit or rollback operation.
Parent topic:
Optimizing performance for commitment control
Related tasks
Detecting deadlocks