Kbase P126765: lkPurge errors since migrating to 10.1B - Associated with User Lock Queues
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
10/11/2009 |
|
Status: Verified
SYMPTOM(s):
lkpurge error received by server process on behalf of remote ABL client.
Error is not fatal therefore no core or protrace files are created.
Did not see lkPurge errors prior to upgrading from 10.0B05 to 10.1B0202
SYSTEM ERROR: lkpurge: record not locked. (13940)
FACT(s) (Environment):
All Supported Operating Systems
OpenEdge 10.1B
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.
If an upgrade is not possible at this time, use this 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.