Share-lock

Krishan Gopal

New Member
Hi All,

I know there are 3 kinds of Locks in Progress Exclusive, Share and No Lock. I know all properties of these locks.
I tried a lot, but I couldn't find the answer of where we can use SHARE-LOCK? As in multiuser it is always suggested to use EXCLUSIVE-LOCK with NO-WAIT NO-ERROR, what could be the use of SHARE-LOCK?

Where exactly we can use SHARE-LOCK except in CAN-FIND function?

Please let me know proper place or situation where we can use SHARE-LOCK.

Thanks!!
 

RealHeavyDude

Well-Known Member
Unless you specify the -NL startup paramter and the lock is not explicitly specified the default lock is SHARE-LOCK. IMHO this is a leftover from the old days where applications weren't really used by many users and for the sake of simplification of programming. Nowadays you should avoid using SHARE-LOCKS because they have the potential of producing dead-locks.

On top of my head I can think of one scenario where I deliberately made use of a share-lock:

I have designed a batch job for which only one instance is allowed to run at a time, all the others should be queued. You could achieve this by storing data about the running job somewhere, even in the database, but, what happens when the job crashes for some reason? The marker for the running job is not cleared, you would need to clear it manually. In this scenario I use a share lock. If the job gets an exclusive lock then I know that no other instance of the job is already running so I start it and downgrade the exclusive lock to a share lock which is held until the job goes out of scope. When another instance of the job tries to start it won't get the exclusive lock and will be queued. When the job that holds the share lock crashes, that share lock will automatically released by the database - so there's no need to manually clear anything.

HTH, RealHeavyDude.
 

RealHeavyDude

Well-Known Member
Here is a sample of what I described in my previous post:

DEFINE BUFFER b_cfp_job FOR cfp_Job.

JOB-BLK:
DO FOR b_cfp_Job ON ERROR UNDO JOB-BLK, RETURN 'ERROR':U ON STOP UNDO JOB-BLK, RETURN 'ERROR':U:

/* Are we - for some reaseon on which to elaborate is beyon the scope of the comment -
already running? Since only one running instance of this job is allowed we need to
make sure ... */
DO TRANSACTION ON ERROR UNDO JOB-BLK, LEAVE JOB-BLK:

/* Locate the job object with an exclusive lock */
FIND b_cfp_Job EXCLUSIVE-LOCK
WHERE b_cfp_Job.jobIdSymbol = 'FTD_DOC_EXPORT':U NO-WAIT NO-ERROR.

/* If we can't get the exclusive lock then we know that another process is holding the share lock ... */
IF NOT AVAILABLE b_cfp_Job OR LOCKED b_cfp_Job THEN DO:

&IF {&EXPORT-MODE} = "INITIALLOAD" &THEN
RUN adj_job_protokoll ( 0, 1, 'ERROR: Ein FTD Doc Export Job (Updates oder InitialLoad) läuft bereits.' ).
UNDO JOB-BLK, RETURN 'ERROR':U.
&ELSE
RUN adj_job_protokoll ( 0, 1, 'WARNUNG: Ein FTD Doc Export Job (Updates oder InitialLoad) läuft bereits.' ).
UNDO JOB-BLK, RETURN 'WARNING':U.
&ENDIF

END.
/* If we have the exclusive lock downgrade to a share lock so we can commit the transaction and still prevent
that another process will get an excluisve lock on the object ... */
ELSE
FIND CURRENT b_cfp_Job SHARE-LOCK.

END. /* TRANSACTION */

/* Do my stuff here ... */

/* Error handling */
CATCH oAnyError AS Progress.Lang.Error:
&IF DEFINED (LOCAL-TEST) <> 0 &THEN
MESSAGE oAnyError:GetMessage ( 1 ) VIEW-AS ALERT-BOX ERROR.
&ELSE
RUN adj_job_protokoll ( 0, 1, oAnyError:GetMessage ( 1 ) ) NO-ERROR.
&ENDIF
DELETE OBJECT oAnyError.
END CATCH.

END. /* JOB-BLK */
HTH, RealHeavyDude.
 

Krishan Gopal

New Member
Thanks a lot "RealHeavyDude", Sorry I couldn't find find any proper name!

So I can assume it as leftover of old Progress Version and generally will not be used in modern applications?
 
Top