Kbase P77743: Record lock remains in database after failed unique FIND
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
7/4/2007 |
|
Status: Unverified
FACT(s) (Environment):
Progress 9.1x
OpenEdge 10.0A
SYMPTOM(s):
Record lock remains in database after failed unique FIND.
Multiple sessions trying to exclusive-lock the same record at the same time.
Key field used in record find is changed in other session.
Session trying to fetch record fails find and continues processing normally.
Record Locking Table in Promon shows share lock remains for second session.
CAUSE:
Bug# OE00103142
CAUSE:
When the second session tries to fetch the record with a lock, the lock manager finds the record is already locked. So this lock request will be queued, as reflected by the Q flag in the locking table.
When the first session releases the record, the second session will momentarily obtain the exclusive-lock. It then checks if the record still matches the WHERE clause. As this is not the case the FIND fails, and the session continues processing accordingly.
At this time, the exclusive lock it momentarily had is downgraded to a share-lock and remains in the database.
FIX:
Upgrade to OpenEdge 10.0B or later release
Workaround:
Lock a record in another table from the session holding the leftover lock.
This will cause the lock manager to clear up the leftover lock.