Progress
Programming
Handbook


Managing Locks to Improve Concurrency

Rather than rely on default locking behavior, you can use a simple lock management algorithm to:

Each time you want to present data to the user for inspection and possible update, follow this procedure:

  1. Request and display the record with the NO–LOCK option.
  2. Let the user manipulate the data until the user signals that they have finished (ON LEAVE OF field, ON CHOOSE OF okbutton, or similar).
  3. Request the same record again using the FIND CURRENT or GET CURRENT statement with the EXCLUSIVE–LOCK option.
  4. Use the CURRENT–CHANGED function to see if the original record has changed since you first presented it to the user.
  5. If the record is the same, commit the change.
  6. If the record has changed, inform the user, display the new data, and repeat the process.

The code example below demonstrates this technique:

p-lock13.p
FORM customer.name customer.balance WITH FRAME upd. 
ON GO OF FRAME upd DO: 
    DO TRANSACTION: 
        FIND CURRENT customer EXCLUSIVE-LOCK. 
        IF CURRENT-CHANGED customer THEN DO: 
            MESSAGE "This record has been changed by another user" 
                    SKIP 
                    "Please re-enter your changes." 
                    VIEW-AS ALERT-BOX. 
            DISPLAY customer.name customer.balance with frame upd. 
            RETURN NO-APPLY.  
        END. 
        ASSIGN customer.name customer.balance. 
    END. 
    FIND CURRENT customer NO-LOCK. 
END. 
FIND FIRST customer NO-LOCK. 
DISPLAY customer.name customer.balance WITH FRAME upd. 
DO ON ENDKEY UNDO, LEAVE: 
    ENABLE customer.name customer.balance WITH FRAME upd. 
    WAIT-FOR "GO" OF FRAME upd. 
END. 

The first problem this technique avoids is the classic “user at lunch” syndrome. If the user begins work on a SHARE–LOCK record and does not finish with it immediately, all other users are prevented from updating the record. The FIND CURRENT technique moves the scope of the transaction between possible user actions. In other words, no user interface manipulation can tie up a record.

Making transactions smaller, or atomic, also improves performance and promotes modular code design that can support many interface styles.

Finally, this technique avoids the “deadly embrace” problem. Deadly embrace occurs when two users have the same record with SHARE–LOCK and both are waiting for the other to release the record. Although this problem can be avoided by good design, using the FIND CURRENT technique means that this will never be a problem.


Copyright © 2004 Progress Software Corporation
www.progress.com
Voice: (781) 280-4000
Fax: (781) 280-4095