The best of both worlds is called "Optimistic Locking" -
You read a record for display without locking it.
If you are going to update, you read the record and keep a copy of the original record.
When you go to write, you read again, this time with a record lock, and compare what you wrote with what you saved.
If there have been changes, you have several things you can do. For example, check to see if the fields that changed in the record are any of the fields you are about to change. If they are not, then bring in the changes to the other fields and write the record.
If there are conflicts, you can let the user figure them out, or let the program figure it out, drop the changed record, or do something more clever.
It is more work, but it is balanced for the best availability and least locking errors with very good data integrity, and while giving the fewest possible access errors.
-Paul
On Aug 05, 2016, at 12:45 PM, Chuck Landress <clandress@xxxxxxxxxxx> wrote:
Actually the procedure you describe is, in my opinion, the best way. You
avoid locking the record if the user has it on their screen for a long time
and you only update if a change has been made.
I worked on a system that read with no lock and then updated (COBOL can do
that). The number of inadvertent overwritten data changes was impressive.
The system I work on currently locks records even on inquiries causing a
lot of system errors due to record locks. That said, we rarely have data
inadvertently overwritten. It sure is difficult to get the users to exit
screens before going to lunch.
--
Chuck Landress, PMP
678-469-2326
"Resistance is futile, you will be assimilated. We are the Bored"
-Unknown
On Fri, Aug 5, 2016 at 1:00 PM, <cobol400-l-request@xxxxxxxxxxxx> wrote:
Send COBOL400-L mailing list submissions to
cobol400-l@xxxxxxxxxxxx
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.midrange.com/mailman/listinfo/cobol400-l
or, via email, send a message with subject or body 'help' to
cobol400-l-request@xxxxxxxxxxxx
You can reach the person managing the list at
cobol400-l-owner@xxxxxxxxxxxx
When replying, please edit your Subject line so it is more specific
than "Re: Contents of COBOL400-L digest..."
Today's Topics:
1. user record updates via a cobol program: how to deal with
record locks and data changes (Stone, Joel)
----------------------------------------------------------------------
message: 1
date: Fri, 5 Aug 2016 16:45:29 +0000
from: "Stone, Joel" <Joel.Stone@xxxxxxxxxx>
subject: [COBOL400-L] user record updates via a cobol program: how to
deal with record locks and data changes
What is a good way to handle record locks when a user changes a DB record
via a cobol pgm?
Also how to avoid one user's changes from overlaying another user's recent
changes.
Is the best way to read with no lock, wait until user enters data into
screen, then re-read with a record lock?
And only update the record if there were no changes between the two reads
by comparing the entire record strings?
Any other methods that work well?
Maybe read the journal to ensure no one else has changed that particular
RRN during the users input?
Thanks!
Joel
------------------------------
Subject: Digest Footer
--
This is the COBOL Programming on the IBM i (AS/400 and iSeries)
(COBOL400-L) digest list
To post a message email: COBOL400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/cobol400-l
or email: COBOL400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at
http://archive.midrange.com/cobol400-l.
------------------------------
End of COBOL400-L Digest, Vol 14, Issue 20
******************************************
midrange.com
