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 code example 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".

/* h-findCustUser1.p */
FIND Customer 3000. // SHARE-LOCK by default
DISPLAY "User 1:" CustNum FORMAT "ZZZ9" NAME FORMAT "X(12)"
  CreditLimit Balance
  WITH FRAME CustFrame.
ON 'LEAVE':U OF Customer.CreditLimit IN FRAME CustFrame
DO:
  ASSIGN Customer.CreditLimit.
END.

ENABLE Customer.CreditLimit Balance WITH FRAME CustFrame.

WAIT-FOR CLOSE OF THIS-PROCEDURE.

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.

Figure 1. Result of two sessions running h-findCustUser1.p procedure

However, if you enter a new value in the Credit Limit 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.
Figure 2. SHARE-LOCK status message

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 do not 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 will not 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.