RE: CHAIN or READ without lock

[Chris Bipes <rpg@xxxxxxxxxxxxxxx>]

We have gone one step further and compare field by field what the current
user has changed, if before and after is not the same.  Then for the fields
changed by the current user, if the field was not changed by another job,
save the changes.  Field level updates has solved many conflict problems.

Christopher K. Bipes     mailto:ChrisB@Cross-Check.com
Sr. Programmer/Analyst   mailto:Chris_Bipes@Yahoo.com
CrossCheck, Inc.         http://www.cross-check.com
6119 State Farm Drive    Phone: 707 586-0551 x 1102
Rohnert Park CA  94928 Fax: 707 586-1884

*Note to Recruiters
Neither I, nor anyone that I know of, is interested in any new and/or
exciting positions. Please do not contact me.


-----Original Message-----
From: Martin, Booth [mailto:BoothM@goddard.edu]
Sent: Friday, February 11, 2000 10:04 AM
To: 'RPG400-L@midrange.com'
Subject: RE: CHAIN or READ without lock


Jim, take a look at Carr & Harvey's solution.  It really is boiler plate,
just as John says.  The idea is to read the record(unlocked) and move the
record's information to a "before" datastructure.  Then, when your user
pushes The "go do it" button, read the record again(locked this time) and
move the record's information to an "after" datastructure. Then, if the
"before" datastructure does not equal the "after" datastructure you know
someone else changed the record so then you can tell the user and go to Plan
B.  Otherwise, update the record and continue.  The feature of this solution
is that the record is never locked while waiting for a keystroke.

-----Original Message-----
From: Jim Langston [mailto:jlangston@conexfreight.com]
Sent: Friday, February 11, 2000 11:11 AM
To: boothm@goddard.edu
Subject: Re: CHAIN or READ without lock


Take the same scenario.  The operator keys in some changes, then goes
and answers the phone without pressing enter.  Meanwhile, another
operator makes some changes on the record, presses enter and updates
the record.  Now the first operator comes back and presses enter, and
updates the record.  The second operator's changes just got stepped on,
and no one is the wiser.  That is the whole reason to read a record while
locking it, you are intending to change the record, and don't want anyone
else able to read it for changes while you have it open.

That is the key, though, read it for changes.  If the operator has the
record
locked and is changing it, a report program can still read the record as it
exists without any difficulties, as long as it is reading it for input only,
no
changes.  Which is how you want it.

Neither is perfect though, I will grant you that.  But, in theory, your
batch
program running should stop and wait for the record to be unlocked before
it continues.  You need to make sure you are waiting long enough for records
to become unlocked before you bomb out.

The only big problem is a dead lock situation.  That is, operator A reads
a record from file 1 for update.  Operator B reads a record from file 2 for
update.  Now, Operator A tries to read the same record from file 2 for
update.  Then, operator B tries to read the same records from file 1 for
update.  It is a deadlock situation.  Operator A's process will never finish
until it reads from file 2, which is locked by operator B.  But operator
B's process won't finish until it reads from file 1, which is locked by
operator A.

Luckily, deadlocks are far and few between, but they do happen.

Regards,

Jim Langston
+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---