Progress
Programming
Handbook
Locks and Multiple Buffers
Progress also uses default behaviors to prevent the condition known as bleeding record locks when multiple buffers use the same record. A bleeding record lock occurs when a buffer with NO–LOCK inherits a SHARE–LOCK from another buffer during a record disconnect.
For example, examine this code:
In this code example, two customer buffers contain copies of the same record. One has it with a NO–LOCK and the other has it with a SHARE–LOCK. When the second FIND statement executes, the NO–LOCK state of acust is upgraded to SHARE–LOCK. When Progress executes the RELEASE statement, the customer record is disconnected from the bcust buffer and its SHARE–LOCK is downgraded to a NO–LOCK. What happens to the acust buffer lock status? If acust retains the SHARE–LOCK, then you can say that the bcust lock bled to acust. This is a bleeding record lock. Fortunately, Progress does not simply release the specific record and lock. It checks all other buffers to see what locks they require. In this case, the acust buffer is downgraded to NO–LOCK. Progress does not allow bleeding record locks to occur in any situation.
NOTE: Progress Version 7.3A and earlier did allow bleeding record locks as described in this section. To preserve application behavior that depended on bleeding locks, use the Bleeding Record Lock (–brl) startup parameter. You might have to use this startup parameter if a working Version 7.3A or earlier Progress application generates the following error messages when compiled under V7.3B or later:
Copyright © 2004 Progress Software Corporation www.progress.com Voice: (781) 280-4000 Fax: (781) 280-4095 |