Re: Leaving records locked. was(Re: Message line: Another approach?)

On Feb 2, 2020, at 3:50 AM, Frank Kolmann <frank.kolmann@xxxxxxxxx> wrote:

I agree with Booth. Leaving records locked for a long time can cause you a host of problems.

Its been a long time since I have done coding. But I just had to but in on this point.
For interactive jobs where you are relying on a user to press the F9 update key, never lock the record on read.
Batch jobs in the main dont need to have competing lock logic, the system manages this for itself.


for example
. A user opens a record for update then goes to lunch. In the meantime another job crashes because it needs the record.
. Multiple jobs attempt to open records for update, and each are waiting for the other to complete,

It is simple to code logic that detects if a record has been updated (I had an update number field) If you dont have an update number you can have the whole record in a DS.
then, nicely ask the user to refresh the screen data with F5 because the record was changed. (If a change is detected)
In my experience this message rarely occurred and when it did happen the recovery was a simple, press F5 and try again. This was a much easier process to manage than to recover crashes.

I implemented a system standard on how updates had to be coded. Programmers disagreed with me and then received poor performance reviews which had other more personal consequences.
I had the code changed by a different programmer or changed it myself.


Am 31.01.2020 um 20:31 schrieb Booth Martin <booth@xxxxxxxxxxxx>

As to the locked record issue; at the very least, why add to the problem? Consider NOT locking on the read chain, rather wait until the update chain.

No. Someone else could update the record then and after UPDATE, the changes from before are gone.
Yes, I could compare field values for changes and try to merge them in a meaningful way. Or rely on the user to pick which values shall get overwritten. Way too much logic when a simple lock prevents this problem >from happening in the first place. I try to adhere to the KISS principle.

Regards Frank
--
This is the RPG programming on IBM i (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/rpg400-l.

Please contact support@xxxxxxxxxxxx for any subscription related questions.

Help support midrange.com by shopping at amazon.com with our affiliate link: https://amazon.midrange.com