Using and upgrading SHARE-LOCKS

If you remove the EXCLUSIVE-LOCK keyword from the FIND statements in both procedures, the AVM reads the record in each case with a SHARE-LOCK by default. The version of the procedure shown in the following figure is saved in the examples as h-findCustUser1.p. For this test, the second user runs the same procedure with the displayed string "User 2".

You can run both procedures at the same time, and they can both access the Customer with a SHARE-LOCK, as shown in the following figure.

However, if you enter a new value in the CreditLimit field for either one and tab out of the field, the AVM tries to upgrade the lock to an EXCLUSIVE-LOCK to update the record. This attempt fails with the message shown in the following figure because the other user has the record under SHARE-LOCK.

If both users try to update the record, they both get the lock conflict message. This situation is called a deadly embrace, because neither user can proceed until one of them cancels out of the update, releasing the SHARE-LOCK so that the other can upgrade the lock and update the record.

To avoid this kind of conflict, it is better to read a record you intend to update with an EXCLUSIVE-LOCK in the first place. If you do this in a server-side business logic procedure, which in a modern application is always the case, you won't see a message if the record is locked by another session. Your session simply waits until the lock is freed. If your record locks are confined to server-side procedures with no user interface or other blocking statements, then the problem of a record being locked indefinitely won't ever happen, and a brief wait for a record is not normally a problem.

By default, the time that a session waits for a record to be unlocked is 30 minutes. However, no message is sent back to the process when the time out value is reached. You can specify a different wait time with the Lock Timeout (-lkwtmo) startup parameter.