Lock Table Overflow is caused by the current application code design with respect to
transaction and record scoping.
Application code needs to be designed so that transactions scope only locks as many records that are strictly needed and that those locks on records are held for the minimum possible time.
To review application transaction and record scope:
- Compile the code using the LISTING option. This will indicate where blocks start and end (sub-)transactions. Alternatively, since OpenEdge 10.1B and later, run suspect jobs with 4GLTrans logging active to show the transaction scope at runtime.
- Use the TRANSACTION and LOCKED ABL functions to determine which records are locked and if a transaction is active.
- Avoid SHARE-LOCK where possible and specify a record lock only when retrieving a record for updates.
- Use the -NL startup parameter, but test thoroughly before deploying this parameter. This will affect future deployed code that relies on the implicit default SHARE-LOCKs.
- Run the application code in single user mode if it is impossible to change the application. Relatively easy to implement for batch processes, but requires downtime for other processing while the program is running.
- For further information refer to Article How to debug "Increase -L" error (915), record locking, transactions?
If the application code is structured correctly for the task it needs to do then the number of lock table entries on the database server need to be increased. This is done by setting the -L startup parameter for the database broker process, in the .pf/command line used with the proserve command, or via the appropriate settings in Progress Explorer/OpenEdge Explorer when the database is managed by the AdminServer. Since OpenEdge 10.1C it can be increased online, refer to Article
To monitor Lock Table entries when isolating "Lock Table Overflow (915)" application transaction scope, the _DBStatus VST can be used.
