Try OpenEdge Now
skip to main content
ABL Essentials
Handling Data and Locking Records : Record locking in ABL : Record locking examples : Using and upgrading SHARE-LOCKS
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".
Figure 44. h-findCustUser1.p 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 45. Result of two sessions running h-findCustUser1.p procedure
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.
Figure 46. 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 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.