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:

p-lock4.p
                     /* USER 1 */  
DEFINE VARIABLE answer AS LOGICAL. 
REPEAT: 
    PROMPT-FOR customer.cust-num. 
    FIND customer USING cust-num. 
    UPDATE name credit-limit sales-rep. 
    SET answer LABEL "Update OK?". 
    IF NOT answer THEN UNDO, NEXT. 
END. 

p-lock5.p
                     /* USER 2 */ 
FOR EACH customer: 
    DISPLAY cust-num name address city state postal-code. 
END. 

Before running either of these procedures, follow these steps to set up the multi-user environment:

  1. Start the multi-user server, using the command appropriate to your operating system.
  2. Operating System
    Syntax
    UNIX Windows
    proserve database-name

    Here, databasename is the name of the database that you want to run multi-user Progress against.

  3. On one terminal (terminal 1), start multi-user Progress with the appropriate command for your operating system.
  4. Operating System
    Syntax
    UNIX Windows
    mpro database-name

  5. 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 press GO. 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.

    customer in use by user1 on ttyi13. Wait or press CTRL-C to stop. 

(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:

p-lock6.p
FOR EACH customer NO-LOCK: 
    DISPLAY cust-num name address city state postal-code. 
END. 

Try running the p-lock4.p procedure again. Once again, enter 1 as the customer number, make any change to the customer record, and press GO. Now go to another terminal and run the p-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 the p-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