Share-Lock?
- Thread starter Kalan
- Start date
jaiprogress
New Member
Hi,
We should never used SHARE-LOCK, It cane create dead-lock condition.
If you want to only read the record use NO-LOCK, if you want to modify the record use EXCLUSIVE-LOCK.
I think it will helpful for u.
We should never used SHARE-LOCK, It cane create dead-lock condition.
If you want to only read the record use NO-LOCK, if you want to modify the record use EXCLUSIVE-LOCK.
I think it will helpful for u.
Kalan
Member
I found one valid example scenario explained by Realy Heavy Dude. Thanks.
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.
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.
MaximMonin
Member
we have scenario: users cannon create/change documents if develeper is changing document form. Or wise versa, developer cannot change form if users edit document.
We use share-lock for this goal when working with documents and exclusive lock when changing document form.
We use share-lock for this goal when working with documents and exclusive lock when changing document form.
RealHeavyDude
Well-Known Member
In modern applications there are almost no valid use cases for a SHARE-LOCK. The SHARE-LOCK comes from the beginning of Progress ( somewhere in the middle of the 1980s ) where concurrency was not a hot topic and for the sake of make coding simpler. The SHARE-LOCK can be automatically upgraded to an EXCLUSIVE-LOCK in case one intends to update a record later some time. That's nice because as soon as one has the SHARE-LOCK one may or may not update that record and one just don't needs to care. But it also introduces the possibility of a dead lock on the database. Since more and more users are using our applications the probability of causing dead locks in using SHARE-LOCKS is much bigger today than it was back then. You need to be aware that the SHARE-LOCK is still the default lock if you don't specify otherwise. You can specify otherwise in adding the -NL startup parameter to the startup of the Progress client session. Otherwise you need to specify the lock in each data-retrieval statement - which is better practice than using -NL, IMHO of course.
Heavy Regards, RealHeavyDude.
Heavy Regards, RealHeavyDude.