Kbase P126811: lkrels errors since migrating to 10.1B - Associated with User Lock Queues
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
10/09/2009 |
|
Status: Verified
SYMPTOM(s):
lkrels errors being reported by users since migrating to 10.1B02
lkrels error occurs during the login process for the client.
SYSTEM ERROR: lkrels record <recid> not locked. (435)
ABL clients are not making use of the -nosavepoint client startup parameter.
FACT(s) (Environment):
All Supported Operating Systems
OpenEdge 10.1B
OpenEdge Category: Database
CHANGE:
Migrated to 10.1B0202
CAUSE:
Bug# OE00151942
CAUSE:
A performance improvement in 10.1B changes the lock backout mechanism in the RDBMS. Previously the entire lock table was scanned row-by-row looking for locks held by the user, and releasing them. Since a lock table can be very large on a big system, this process took a considerably long time. Instead of this linear search, the RDBMS now uses a list of locks held by each user, so releasing locks is very efficient by comparison.
However in 10.1B02 if a connection to the database was killed during a transaction and a record lock had been acquired before starting that transaction, and if there were locks on the same lock chain held by other users, then the cleanup code which backed out the transaction would erroneously remove all the locks on the chain regardless of whether or not the lock actually belonged to the transaction.
FIX:
Upgrade to OpenEdge 10.1B03 or later.
Workaround:
Use -lkrela database startup parameter to revert the database engine to use the previous lock release mechanism until a fix for the defect is available.