Progress
Programming
Handbook
Resolving Locking Conflicts
You can use the following options to resolve locking conflicts and to describe the way you want to lock records:
For example, if you know you are going update a record, you can use the EXCLUSIVE–LOCK option with the FIND statement, as shown in the following procedures:
Before running either of these procedures, follow these steps to set up the multi-user environment:
- Start the multi-user server, using the command appropriate to your operating system.
Here, database–name is the name of the database that you want to run multi-user Progress against.
- On one terminal (terminal 1), start multi-user Progress with the appropriate command for your operating system.
- On a second terminal (terminal 2), enter the same command to start another multi-user Progress session for the same database.
You are now running two users in a multi-user environment.
On terminal 1 run the
p-lock4.p
procedure. Enter 1 in response to the PROMPT–FOR statement. Make some change to the record for customer 1 and then pressGO
. The SET statement prompts you to verify the changes you made.
![]()
On terminal 2, run the
p-lock5.p
procedure. Progress displays a message telling you that the record is in use by another user.
(This message is system specific; it names the appropriate user and device on each system.)
The UPDATE statement places an EXCLUSIVE–LOCK on the customer record 1. That lock is in effect until the end of the transaction, which means Progress locks the record while it prompts you to verify your updates. Meanwhile, the user on terminal 2 cannot read the record for customer 1 because the user on terminal 1 has that record EXCLUSIVE–LOCKed.
At this point, you can press
STOP
on terminal 2 if you do not want to wait for terminal 1 to release the record. But do not do that right now. Go to terminal 1 and answer YES. You now see customer information on terminal 2.When you answer YES on terminal 1, Progress completes the SET statement and reaches the end of the REPEAT block, which is also the end of the transaction in the
p-lock4.p
procedure. Progress releases EXCLUSIVE–LOCKs at the end of the transaction, making the record available to other users.Imagine that, instead of EXCLUSIVE–LOCKing the customer record, the user at terminal 1 SHARE–LOCKed the record. Meanwhile, the user at terminal 2 came along and SHARE–LOCKed the record. Now suppose that both users want to update the record. They both need an EXCLUSIVE–LOCK on the record. But the user at terminal 1 cannot EXCLUSIVE–LOCK the record because the other user has the record SHARE–LOCKed. And the user at terminal 2 cannot EXCLUSIVE–LOCK the record because the other user has it SHARE–LOCKed. This situation is known as deadly embrace. One of the two users must press
STOP
to resolve the situation.There are ways to avoid this situation. For example, if you know you are going to update a record, you can read that record with EXCLUSIVE–LOCK. Alternatively, where you run a reporting procedure, such as
p-lock5.p
, you might not need to see the data that is in flux. You can use the NO–LOCK option to tell Progress to let you see the record even if it is EXCLUSIVE–LOCKed:
Try running the
p-lock4.p
procedure again. Once again, enter 1 as the customer number, make any change to thecustomer
record, and press GO. Now go to another terminal and run thep-lock6.p
procedure.This time, Progress lets the
p-lock6.p
procedure see customer 1 because the NO–LOCK option ignores the EXCLUSIVE–LOCK placed on that customer record by thep-lock4.p
procedure.There are two functions you can use when working with locking situations: AVAILABLE and LOCKED. See the Progress Language Reference for information and examples for using these functions to manage record-locking conflicts.
Copyright © 2004 Progress Software Corporation www.progress.com Voice: (781) 280-4000 Fax: (781) 280-4095 |