Progress 4GL Exclusive Lock Not Releasing - session

Question

I'm using proserve to enable multiple-user session.
This is my code in a mouse double-click trigger on my browse:
DO WITH FRAME MAIN-FRAME:
IF EMP-BROWSE:NUM-SELECTED-ROWS > 0 THEN
DO:
EMP-BROWSE:FETCH-SELECTED-ROW(1).
FIND CURRENT EMPLOYEE NO-ERROR NO-WAIT.
IF AVAILABLE (EMPLOYEE) THEN
DO:
DO TRANSACTION ON ERROR UNDO, LEAVE:
C-Win:SENSITIVE = NO.
FIND CURRENT EMPLOYEE EXCLUSIVE-LOCK.
MESSAGE STRING(EMPLOYEE.emp-num) + " locked.".
C-Win:SENSITIVE = YES.
END.
RELEASE EMPLOYEE.
END.
ELSE IF NOT AVAILABLE (EMPLOYEE) THEN
DO:
MESSAGE "The employee details is currently in-use in another session. Please try again later." VIEW-AS ALERT-BOX TITLE "System Message".
RETURN NO-APPLY.
END.
ELSE
DO:
MESSAGE "The record has been deleted in another session.".
RETURN NO-APPLY.
END.
END.
END.
SCENARIO:
Session A double clicks on browse record 1. It will then message something like "2001 locked." after that Session B double clicks on browse record 1 and it will fire the message at the IF NOT AVAILABLE (EMPLOYEE) block.
My question is shouldn't the RELEASE EMPLOYEE code enable session B to access the same record?
I have also tried FIND CURRENT EMPLOYEE NO-LOCK and putting either of the code inside and outside the DO TRANSACTION block but nothing happens.
EDIT:
I applied these changes but in the same scenario, Session B gets the message on the ELSE block which is MESSAGE "The record has been deleted in another session.". What am I doing wrong here?
When I add a call to a new window RUN newWindow.w. after MESSAGE STRING(EMPLOYEE.emp-num) + "locked."., with the same scenario while not closing the new window on Session A I get a proper response of the record being used in another session in Session B.
DO WITH FRAME MAIN-FRAME:
IF EMP-BROWSE:NUM-SELECTED-ROWS > 0 THEN
DO:
EMP-BROWSE:FETCH-SELECTED-ROW(1).
FIND CURRENT EMPLOYEE NO-LOCK NO-ERROR NO-WAIT.
DEFINE VARIABLE iOk AS LOGICAL NO-UNDO.
DEFINE BUFFER myEMPLOYEE FOR EMPLOYEE.
iOk = NO.
DO FOR myEMPLOYEE TRANSACTION:
FIND myEMPLOYEE WHERE myEMPLOYEE.emp-num = EMPLOYEE.emp-num EXCLUSIVE-LOCK NO-ERROR NO-WAIT.
IF AVAILABLE (myEMPLOYEE) THEN
DO:
IF LOCKED (myEMPLOYEE) THEN
DO:
MESSAGE "The employee details is currently in-use in another session. Please try again later." VIEW-AS ALERT-BOX TITLE "System Message".
RETURN NO-APPLY.
END.
ELSE
DO:
C-Win:SENSITIVE = NO.
MESSAGE STRING(EMPLOYEE.emp-num) + " locked.".
C-Win:SENSITIVE = YES.
END.
END.
ELSE
DO:
MESSAGE "The record has been deleted in another session.".
RETURN NO-APPLY.
END.
END.
END.
END.

Answer 1

RELEASE does not do what you think it does. Use of RELEASE is a red flag. It almost always means that the coder does not have a firm grasp of record and transaction scoping issues.
From the docs:
RELEASE
Verifies that a record complies with mandatory field and unique index definitions. It clears the record from the buffer and unites it to the database if it has been changed.
Notice how the definition says nothing about locks?
Embedding user interface within a transaction is a major mistake -- doing that essentially guarantees that you will have lock contention issues and scalability problems going forward.
As Jens points out your whole approach needs rethinking.
In order to properly control the record and transaction scope the best practice is to be very explicit about it and confine the update to a very tight block of code. Ideally you encapsulate it in a procedure or function like so:
function updEmpName returns character ( input empNum as character, input newName as character ):
define buffer employee for employee.
do for employee transaction:
find employee exclsuive lock where employee.employeeNum = empNum no-error.
if locked employee then
return "locked".
else if available employee then
do:
assign
employee.name = newName.
.
return "updated".
end.
else
return "no such employee".
end.
end.
If you cannot put the update in a function or procedure then you need to "strong scope" the buffer being used to update the record:
define variable ok as logical no-undo.
define buffer updEmployee for employee.
ok = no.
do for updEmployee transaction:
find updEmployee exclusive-lock where updEmployee.employeeNum = empNum no-error.
if available updEmployee then
assign
/* update whatever fields are needed */
ok = yes
.
end.
The "DO FOR updEmployee" is called "strong scope". That means that there cannot be "free references" to the updEmployee buffer outside that block. If the compiler complains that there is a problem then you need to fix it becuase your scope f not what you think it is.

Answer 2

I think you have some things to reconsider here.
This row:
FIND CURRENT EMPLOYEE NO-ERROR NO-WAIT.
Will result in a SHARE-LOCK. Some people (including me) tend to avoid those. I would change into:
FIND CURRENT EMPLOYEE EXCLUSIVE-LOCK NO-ERROR NO-WAIT.
The row after:
IF AVAILABLE (EMPLOYEE) THEN
Will only deal with the existence of the record - not it's locking status. All in all, consider the online (F1) help:
LOCKED function
Returns a TRUE value if a record is not available to a prior FIND . . . NO-WAIT statement because another user has locked a record.
AVAILABLE function
Returns a TRUE value if the record buffer you name contains a record and returns a FALSE value if the record buffer is empty.
FIND...NO-ERROR
Suppresses ABL errors or error messages that would otherwise occur and diverts them to the ERROR-STATUS system handle. If an error occurs, the action of the statement is not done and execution continues with the next statement. If the statement fails, any persistent side-effects of the statement are backed out. If the statement includes an expression that contains other executable elements, like methods, the work performed by these elements may or may not be done, depending on the order the AVM resolves the expression elements and the occurrence of the error.
FIND...NO-WAIT
Causes FIND to return immediately and raise an error condition if the record is locked by another user (unless you use the NO-ERROR option on the same FIND statement). For example:
You could change this into (and the ELSE statement to something like):
FIND CURRENT EMPLOYEE EXCLUSIVE-LOCK NO-ERROR NO-WAIT.
IF LOCKED(EMPLOYEE) THEN DO:
MESSAGE "Locked by another user".
END.
ELSE DO:
IF AVAILABLE (EMPLOYEE) THEN DO:
MESSAGE "Go ahead and change".
END.
ELSE DO:
MESSAGE "Not available".
END.
END.
Have in mind that you are writing code that's a mix between GUI, data access and business logic. This is a bad practice. You can do it for smaller examples, tests and things like that but you should actually avoid it. Even if you're not using AppServer right now you will most likely want to do that in the future - if the code already have nice separation of concern (for instance GUI, business logic and data access) future modernization will be so much easier.

Answer 3

The command FETCH-SELECTED-ROW() already put the selected record in browse into the record buffer using the LOCK that's defined within BROWSE definition, then you don't need to use a FIND statement to do so. Anyway, when I need to do things like you trying to do I use a code like this one :
DO WITH FRAME {&FRAME-NAME}:
DO iCount = 1 TO brEmployee:NUM-SELECTED-ROWS:
brEmployee:FETCH-SELECTED-ROW(iCount).
IF AVAIL Employee THEN DO:
FIND CURRENT Employee EXCLUSIVE-LOCK.
/* Do whatever I need */
FIND CURRENT Employee NO-LOCK.
END.
ELSE DO:
IF LOCKED(Employee) THEN DO:
MESSAGE 'Record locked!'
VIEW-AS ALERT-BOX INFO BUTTONS OK.
END.
ELSE DO:
MESSAGE 'Record deleted!'
VIEW-AS ALERT-BOX INFO BUTTONS OK.
END.
END.
END.
END.
In this example, the FETCH-SELECTED-ROW() aways return the record. If it isn't available you can check LOCKED condition. To avoid the browse to return records that doesn't exist in database you can use -rereadnolock session parameter.
But you're using the code within MOUSE-SELECT-DBLCLICK event of your browse. Then, you can replace the code with something like this :
DO WITH FRAME {&FRAME-NAME}:
brEmployee:SELECT-FOCUSED-ROW() NO-ERROR.
IF AVAIL Employee THEN DO:
FIND CURRENT Employee EXCLUSIVE-LOCK.
/* Do whatever I need */
FIND CURRENT Employee NO-LOCK.
END.
ELSE DO:
IF LOCKED(Employee) THEN DO:
MESSAGE 'Record locked!'
VIEW-AS ALERT-BOX INFO BUTTONS OK.
END.
ELSE DO:
MESSAGE 'Record deleted!'
VIEW-AS ALERT-BOX INFO BUTTONS OK.
END.
END.
END.
Hope it helps.