Salesforce

SYSTEM ERROR 6028 after a Lock Table Overflow (915) error

« Go Back

Information

 
TitleSYSTEM ERROR 6028 after a Lock Table Overflow (915) error
URL NameSYSTEM-ERROR-6028-after-a-Lock-Table-Overflow-915-error
Article Number000186424
EnvironmentProduct: OpenEdge
Version: 10.1C and later
OS: All supported platforms
Question/Problem Description
The following errors are seen one after the other on a client session:
Lock table overflow, increase -L on server (915)
SYSTEM ERROR: A/R block doesn't match caller's. Transaction inconsistency. (6028)
Steps to Reproduce
Clarifying Information
This client session does not crash but the current transaction is undone after the Lock table overflow.

Application uses trigger based code to keep track of changes in a secondary database.


 
Error MessageLock table overflow, increase -L on server (915)
SYSTEM ERROR: A/R block doesn't match caller's. Transaction inconsistency. (6028)
Defect Number
Enhancement Number
Cause
This is expected behavior:
  • The Lock table overflow error is encountered when writing changes to a record in one database, then executing a database trigger that implements programmatic (Trigger-based) code to write records to a second database.
  • Initially, checking the Lock Table for the database that the original transactional program was operating on, showed that sufficient Lock Table entries were allocated for the locks being acquired by all of the connected users.  (PROMON > R&D > 1 > 13)
  • After analysing the database logs for all connected databases, the Lock table overflow 915 error showed up in the database that records written to by the trigger. The Lock table overflow 915 error in the primary database was being shown on behalf of the secondary database in addition to the 6028.
  • The Transaction Inconsistency (6028) error was encountered due to the fact that the transaction was being rolled back (UNDO) from within a nested sub-transaction on a secondary database connection.  In this case, this 6028 error is irrelevant to the root cause of the problem.
  • This was originally hidden because the line of code in the ABL Stack Trace did not show the trigger, but rather the end of a transaction (indicating a trigger program is about to or just finished executing).
  • After examining the allocation vs the usage of the Lock Table in the secondary database it became clear that more Lock Table entries were needed. (PROMON > R&D > 1 > 13)


 
Resolution
Increase the Lock Table entries to a more appropriate value to accommodate the transaction scope of the procedure, using the -L database startup parameter.

Since OpenEdge 10.1C the size of the Lock Table can be increased online. Refer to article 00012486 for more information (link in the Notes section).
  •  
Workaround
 
Notes
Keyword Phrase
Last Modified Date2/25/2021 6:13 PM

Powered by