Kbase P96147: What is a Bleeding Record Lock?
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
4/12/2010 |
|
Status: Verified
GOAL:
What is a Bleeding Record Lock?
GOAL:
Locks and Multiple Buffers?
GOAL:
Bleeding Record Lock (-brl) startup parameter?
GOAL:
What occurs when using -brl startup parameter?
GOAL:
In what conditions can a bleeding record lock occur?
FACT(s) (Environment):
All Supported Operating Systems
Progress/OpenEdge Product Family
FIX:
Progress 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.
Example of code that exhibits the problem:
DEFINE BUFFER acust FOR customer.
DEFINE BUFFER bcust FOR customer.
DO TRANSACTION:
FIND acust WHERE acust.cust-num = 1 NO-LOCK.
FIND bcust WHERE bcust.cust-num = 1 SHARE-LOCK.
RELEASE bcust.
END.
DO TRANSACTION:
acust.name = acust.name + "+".
END.
In the above code, 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. Here is what occurs with a bleeding record lock.
1. When the second FIND statement executes, the NO-LOCK state of acust is upgraded to SHARE-LOCK.
2. 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.
3. Acust retains the SHARE-LOCK
The above situation can be looked as bcust lock bled to acust.
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.