Kbase P100701: How to debug "Increase -L" error (915), record locking, transactions?
Autor |
  Progress Software Corporation - Progress |
Acesso |
  Público |
Publicação |
  1/7/2008 |
|
Status: Verified
GOAL:
How to debug "Increase -L" error (915), record locking, transactions?
GOAL:
Troubleshooting Error (915)
GOAL:
Excessive Locks running an application
GOAL:
What is a Lock table overflow
GOAL:
Possible causes of Error (915)
GOAL:
Error (915) and excessive Lock
GOAL:
Causes of the Lock table overflow error
GOAL:
How to debug the Lock table overflow error?
FACT(s) (Environment):
All Supported Operating Systems
Progress/OpenEdge Versions
FIX:
When you get the following message running an application: Lock table overflow, increase -L on server (915)
Increasing the -L startup parameter on the PROGRESS SERVER (proserve command) gets around the problem, but more records remain locked thus creating a greater likelihood of other users attempting to access locked records.
Running the procedure in single-user bypasses PROGRESS record-locking. If your process involves a large transaction and you do not want to exclude active users from updating locked records, consider running the process in single-user, batch, or both at a time when users are not actively updating records.
Making transactions smaller within your procedure locks fewer records and avoids having to increase the lock table (-L) startup parameter.
One method of lowering the scope of your transaction is to put a DO TRANSACTION: block directly around the statement that updates the record. If the scope of the record you are updating is higher than the scope of the transaction, however, PROGRESS holds on to a SHARE-LOCK for each record until the end of the record scope. The RELEASE statement allows you to explicitly release a SHARE-LOCKed record after the statement which updates the database has occurred.
What is a record's scope?
The block in which it was first referenced in your procedure or in a calling procedure. Use the COMPILE with the LISTING option to determine a record's scope. Note that any reference to a record, before the first block in the program, scopes that record to the procedure block. The procedure block does not end until program end. Therefore record locks being held until the end of the record scope are held for the duration of the program unless you explicitly release the lock with the RELEASE statement.
What is transaction scope?
The outermost block with transaction properties that updates the database. Statements that update the database include: UPDATE, CREATE, ASSIGN and SET. Blocks with transaction properties include: FOR EACH, REPEAT, PROCEDURE, DO TRANSACTION, a block that specifies EXCLUSIVE-LOCK and any block that has the TRANSACTION keyword. Use the PROGRESS istrans.p procedure to determine if there is already an active transaction in your procedure (see next paragraph for details). Note that PROGRESS allows only one active transaction at a time, so the next transaction that you start in your procedure is actually a subtransation. Also note that if you start a transaction in one procedure and it has not ended when you call a sub-procedure, new transactions in the sub-procedure will also be subtransactions.
ONLINE PROCEDURES OR UTILITIES:
You can run the debugging procedure istrans.p anywhere from within your program to determine if there is a transaction active. This procedure is located in the directory: %DLC%\src\samples
The Database Monitor - Option 4 Record Lock Table. The monitor displays current record locks being held. See The PROGRESS System Administrator's Guide for information on how to use this utility.
The COMPILE LISTING option gives information on where records and transactions within your program are scoped.