Kbase P112048: 4GL/ABL: Error (5407) and (5635) using client session -rereadnolock startup parameter.
Autor |
  Progress Software Corporation - Progress |
Acesso |
  Público |
Publicação |
  12/1/2008 |
|
Status: Verified
SYMPTOM(s):
4GL/ABL: Error (5407) and (5635) using client session -rereadnolock startup parameter.
WARNING: -nb exceeded. Automatically increasing from <old value> to <new value>. (5407)
SYSTEM ERROR: -s exceeded. Raising STOP condition and attempting to write stack trace to file 'procore'. Consider increasing -s startup parameter. (5635)
A procedure in the application defines a Session Database FIND Trigger. In the Session Database FIND Trigger code, there is a call to another 4GL/ABL procedure which does another FIND against the same table. For example:
DEFINE VARIABLE i AS INTEGER NO-UNDO.
ON FIND OF Customer
DO:
i = i + 1.
MESSAGE i
VIEW-AS ALERT-BOX INFO BUTTONS OK.
RUN callee.p.
END.
FIND FIRST customer NO-LOCK.
The called procedure has a FIND or a FOR against the same table referenced in the session's Database FIND Trigger:
/* callee.p */
FIND LAST customer NO-LOCK.
FACT(s) (Environment):
All Supported Operating Systems
Progress 9.x
OpenEdge 10.x
CAUSE:
The use of the -rereadnolock parameter causes the FIND TRIGGER to fire whenever a FIND or a FOR statement is executed regardless of its LOCK type. Since the the FIND trigger invokes a procedure that itself executes another FIND or another FOR against the same table, the FIND TRIGGER fires again and a recursive infinite trigger invocations cycle results culminating in the generation of the above errors.
When the -rereadnolock parameter is NOT used, the code above would not generate these errors because the FIND TRIGGER did NOT generate the recursive infinite trigger invocations cycle as above.
FIX:
When using the -rereadnolock, ensure that your application logic does not allow any database FIND trigger to generate a recursive trigger invocations cycle similar to the situation described above. For example, the Customer record values fetched in the calling procedure above could have been passed to the called procedure to avoid executing FIND or FOR statements in the called procedure.