How to trap condition thrown by Lock Wait Timeout (-lkwtmo)

How to trap the STOP condition thrown by Lock Wait Timeout (-lkwtmo)

 

When a lock on a record is attempted, and it is found that the record is already locked, depending upon how the code was written the session may end up in a wait state that will last until the interval specified in the -lkwtmo parameter is satisfied.

After the -lkwtmo interval has elapsed, if the record is still locked by another user, the STOP condition is thrown within the program the lock was attempted.  This condition can stop further execution of the program in question, however it may be desirable for the process to continue executing.
 

To avoid the STOP condition that is thrown ending program execution,

1.  Add an ON STOP condition to the block containing the failed record retrieval statement.

Example: Test for the STOP condition within the block where the lock is attempted
 

DO ON STOP UNDO, LEAVE:
  FIND FIRST <tablename> EXCLUSIVE-LOCK.
END.

MESSAGE "hi " AVAILABLE(<tablename>) 
VIEW-AS ALERT-BOX INFO BUTTONS OK.

2. Alternatively, use NO-WAIT with NO-ERROR and check if the record is locked until the lock is released: 

Example:
 

ETIME(TRUE). 

REPEAT: 
    FIND FIRST <tablename> EXCLUSIVE-LOCK NO-WAIT NO-ERROR. 
        IF NOT LOCKED <tablename> OR 
        ETIME GT 10000 /* 10000 milliseconds = 10 seconds */ THEN LEAVE. 
END. 

IF LOCKED <tablename> THEN DO: 
    MESSAGE "The record is locked" VIEW-AS ALERT-BOX. 
    LEAVE. 
END.

Since OpenEdge 11.7, the "-catchStop 1" feature can be used to CATCH a STOP condition. Refer to Article  How to use -catchStop to trap error 8812   
 

Progress Articles:

 Graceful Recovery from Locked Records  
 4GL/ABL: How to Implement the Optimistic Locking Strategy to manage record locking in a Multi-User Environment?  
 Trap AppServer lock wait time out with ON STOP Phrases  
 How to prevent error 2624 being displayed when a record is locked by another user  
 Records locked that do not match search criteria