Progress Quiz 18

Qn 18: What is the default locking level for reading records in Progress? Give some reasons why this should be used or not!
Ans: Default locking when no explicit lock is given is SHARE-LOCK.

When another user reads the same record and starts updating, the record gets locked for the second user. If then, the first user starts updating, he needs to wait till the second user releases.

It is best to read the record in NO-LOCK if it is display only purpose.

It is best to read the record in EXCLUSIVE-LOCK if it is for update, so others can retrieve only in NO-LOCK mode.
 

TomBascom

Curmudgeon
You cannot update a record that you do not have an EXCLUSIVE-LOCK on.

If someone already has a SHARE-LOCK then another user's attempt to obtain that record with EXCLUSIVE-LOCK will either fail (if you say NO-WAIT) or block. That is generally undesirable.

You can always read a record NO-LOCK. Even if someone else has an EXCLUSIVE-LOCK on it.
 

TomBascom

Curmudgeon
That's nice. But if someone forgets to put -NL in their startup parameters you're back to "the default is SHARE-LOCK".
 

Stefan

Well-Known Member
That's nice. But if someone forgets to put -NL in their startup parameters you're back to "the default is SHARE-LOCK".
-NL is read at compile time. I am going on the assumption that only r-code is deployed and no source code. The compile time build environment must be in source control. Test / development environments should be in source control.
 

TomBascom

Curmudgeon
Sure. But you’re still depending on someone keeping that parameter present in the environment. There are lots of other behaviors that could have been controlled with similar mechanisms but are not. IMHO that’s because it was realized that this is an unreliable way to do it.
 

Stefan

Well-Known Member
Any attempts at breaking the build environment by accident can be caught by a unit test or by the sonar-openedge shared lock record access rule.

This rule raises an issue whenever a FIND / FOR / OPEN QUERY statement has no NO-LOCK / EXCLUSIVE-LOCK option, resulting in a SHARE-LOCK. Shared locks are more expensive than NO-LOCK in terms of server resources, and it's always better to specify the kind of lock you want to use.

Although I am unsure if this also fails when -NL.

But I have to admit that we /always/ use NO-LOCK and we also have -NL set to catch out anyone trying to not use NO-LOCK.

It's just such a pity that all this unfortunate default behavior resulting from design decisions made in the eighties is still polluting source code with noise, NO-UNDO being an example of another the other major source code polluter.
 

TomBascom

Curmudgeon
One more thing ;). I don't think you actually "catch out" people who forget NO-LOCK. The use of -NL doesn't generate a warning or error when it changes the default behavior, it just quietly protects you from someone having done it wrong. To catch someone, and then hopefully correct the code, you need Sonar or something along those lines.
 

Stefan

Well-Known Member
Remember that I'm all for less noise words. So in an ideal world I would remove all no-locks and add it to the keyword forget list.

-NL will catch out people who forget to add exclusive-lock when they want to manipulate the record.
 

TomBascom

Curmudgeon
That would be nice. While we're at it NO-UNDO should be the default and likewise be added to said keyword forget list ;)

Yes, but it won't catch them until they try do do it. And if their code is that bad then their testing also probably sucks and thus it is unpleasantly likely that a user will be the one who gets caught out.
 

Stefan

Well-Known Member
Yes, but it won't catch them until they try do do it. And if their code is that bad then their testing also probably sucks and thus it is unpleasantly likely that a user will be the one who gets caught out.
Oh, but just set the sonarqube quality gate to at least 100% code coverage - problem solved :)
 
Top