Kbase P20826: A record is queuing for a lock but nothing else has it
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
22/04/2004 |
|
Status: Unverified
FACT(s) (Environment):
Progress 9.1x
FACT(s) (Environment):
Caldera Open UNIX 8
SYMPTOM(s):
Record lock request remains in database.
Multiple sessions trying to 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 lock with Q flag.
CAUSE:
Bug# 20020508-001
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.
Because the key value is changed by the first session to lock the record, the find fails. The 4GL will handle this normally, but the lock manager will not clean up the queued lock at this time.
FIX:
Upgrade to OpenEdge 10.0A or later release.
Workaround:
Lock a record in another table from the session holding the leftover lock.
The lock manager will clear up the leftover lock.