Progress
Programming
Handbook
How Progress Applies Locks
You’ve just seen how you can apply a lock on your own. But if you do not apply any locks, Progress performs default locking. In particular:
- Whenever it reads a record, Progress puts a SHARE–LOCK on that record. (An exception is the browse widget. See the section "Bypassing Progress Lock Protections" for more information.) This means that other users can read the record but cannot update it until the procedure releases the SHARE–LOCK. If you try to read a record with a SHARE–LOCK when another user has that record EXCLUSIVE–LOCKed, Progress displays a message that the record is in use and you must wait to access it.
- Whenever Progress updates a record, it puts an EXCLUSIVE–LOCK on that record. This means that other users cannot read or update that record until the procedure releases EXCLUSIVE–LOCK. If you try to read a record with an EXCLUSIVE–LOCK, when another user has that record SHARE–LOCKed or EXCLUSIVE–LOCKed, you receive a message that the record is in use and you must wait to access it.
NOTE: SHARE–LOCKs and EXCLUSIVE–LOCKs use up entries in the lock table. The possible number of entries in the lock table defaults to 500. You can change this with the Lock Table Entries (–L) startup parameter. Progress stops a user program if it attempts to access a record that overflows the lock table.In Figure 13–3, when the FIND statement reads the customer record, Progress puts a SHARE–LOCK on that record. Because the UPDATE statement lets you change the record, Progress upgrades the SHARE–LOCK to an EXCLUSIVE–LOCK after the UPDATE statement executes.
p-lock3.pFigure 13–3: How Progress Applies Locks
![]()
Copyright © 2004 Progress Software Corporation www.progress.com Voice: (781) 280-4000 Fax: (781) 280-4095 |