Salesforce

How to use -catchStop to trap error 8812

« Go Back

Information

 
TitleHow to use -catchStop to trap error 8812
URL NameHow-to-use-catchStop-to-trap-error-8812-000087056
Article Number000125606
EnvironmentProduct: OpenEdge
Version: 11.7 and later
OS: All supported platforms
Question/Problem Description
How to use -catchStop to trap error 8812 and provide more information about the record locked by another user at the time
When eventually the Lock wait timeout expires it is useful to know the table name that the session was waiting on for further application code debugging

How to further debug concurrency issues due to locked records exceeding -lkwtmo
Lock wait timeout of <seconds> expired (8812) 

When a record is not available since locked, who is holding that record and which table?

When the record is still locked by another user after the -lkwtmo interval has elapsed, a STOP condition is thrown within the program the lock was attempted and 8812 is raised without sufficient information to troubleshoot the issue after the fact.

proGetStack will include the list of Persistent procedures/Classes, to narrow down the list to find where in your code you are accessing the affected table, the table name needs to be known from the 8812 stop condition
Steps to Reproduce
Clarifying Information
Error Message
Defect Number
Enhancement Number
Cause
Resolution
In OpenEdge 11.7, the new "-catchStop 1" feature can be used to CATCH a STOP condition. In this case it will be represented by a Progress.Lang.LockConflict object that is raised when the lock-out occurs.  
  • To get STOP, the session has to time out waiting for the lock - or the user has to see that lock conflict dialog and cancel out of it.  
  • If you CATCH a LockConflict object, it will have information on the name of the table, device and user that is holding the lock.
  • The LockConflict object will also have the stack trace of the session waiting that eventually exceeds -lkwtmo on the record lock.  The stack trace of the session holding the lock will be in another process and we don't keep track of what line of code was executing when locks are obtained.
  • The Progress.Lang.LockConflict object is only raised when the NO-WAIT option is not used on the FIND statement, because a NO-WAIT will raise an ERROR, not STOP.  
Example:  User X cannot get an exclusive lock for a particular record, identify the user Y holding the lock on this record 

The code below demonstrates the Progress.Lang.LockConflict Object using the sports2000 database's Customer table.

Session 1:  prowin dbname -lkwtmo 10 
 
BLOCK-LEVEL ON ERROR UNDO, THROW.
 
DO TRANSACTION:
    FIND FIRST customer EXCLUSIVE-LOCK.
    NAME = NAME + ".".
    VALIDATE Customer.
    PAUSE.
    RELEASE Customer.
END.

Session 2:  prowin dbname -lkwtmo 10 -catchStop 1 -debugalert -errorstack
 
BLOCK-LEVEL ON ERROR UNDO, THROW.
 
DO TRANSACTION:
    FIND FIRST customer EXCLUSIVE-LOCK.
    NAME = NAME + ".".
    VALIDATE Customer.
    /*    PAUSE. */

 
    CATCH se AS Progress.Lang.LockConflict:
         MESSAGE "Record Lock conflict"
         se:Device se:User se:TableName SKIP
         se:CallStack VIEW-AS ALERT-BOX.
    END CATCH.
    
    CATCH e as Progress.Lang.Error:
        MESSAGE e:getmessage(1) SKIP
         VIEW-AS ALERT-BOX.
    END CATCH.

END.
   
MESSAGE "done and dusted!" .

 
Workaround
Notes
References to Other Documentation:

Progress Documentation

11.7 OpenEdge Development: ABL Reference, Class, Interface, and Enumeration Reference : Progress.Lang.LockConflict class
11.7 OpenEdge Getting Started: New and Revised Features, What's New in 11.7 : OpenEdge ABL enhancements : Handling STOP conditions using stop objects

Progress Article:
 Is there a request to add more information to the current 8812 message?  
Keyword Phrase
Last Modified Date11/20/2020 7:11 AM

Powered by