Tweet
When the combination of setll and reade using a partial key results in eof (key not found), will some record in the file be locked? I have a program causing a record contention problem, and this combination is the only time the program reads the file without unlocking the record with either an update or a delete.
-
-
There should be no lock. Since no record was found. Easy enough to test though, Write a tiny program with nothing except a file definition, a setll (for an impossible record) and a reade. Make the program wait at that point (or run it in debug to achieve that) and look for record locks on the file. That will prove it one way or another.
Is this an interactive app? In which case are you holding a lock because you lock the record and then wait for the user to provide updates? In my experience that is the most common cause of this kind of problem. -
It is a well known issue.
In the RPG reference manual you can find this for READE
Note: If a file is defined as update and the N operation extender is not specified, occasionally a READE
operation will be forced to wait for a temporary record lock for a record whose key value does not match
the search argument. Once the temporary lock has been obtained, if the key value does not match the
search argument, the temporary lock is released.
This means that it tries to lock the next record even though the key does not match.
And if somebody has a lock on the "next record" then it fails.
Normally I read the records with READE(N) and then CHAIN it with LOCK if it should be changed.Last edited by Peder Udesen; April 6, 2020, 01:36 AM.Comment
-
But that wouldn't cause lock contention - or at least this program would not be the cause surely Peder? It is a transitory lock that is in place for a minuscule period of time (it doesn't ever even rise up to the RPG level). So if this program appears to experience a problem it should only be as a result of another program holding a record lock - not the one under discussion.
-
-
Sorry, I don't know the word "contention".
What does it mean in this situation?
Neither my old dictionary nor my old Oxford Advanced Learner's Dictionary gives me an explanation that I can use.
What are the symptoms of the situation that LBurkett99 asks about?
Comment
-
Contention is just a record lock conflict in this context. "Contend" as in competition for a lock. The OP appears to think that _this_ program is retaining a lock in an EOF situation. But that can't happen. It may appear to get hung while waiting for another program to release a lock - but it will never leave the record locked. So I think he needs to look elsewhere.
-
-
OK -- it's something like a good old fasioned deadlock.
Well, many things can cause this.
But if it is the same file in the same program then you will not experience a lock.
If a record lock existed at the time a setll / reade was executed then the record lock
was released and a new record lock established.
At EOF no record lock wil exist.
If there are two or more indexes opened for update on the same physical file then the possibility for a dead lock exists,
given a record lock is established for one index and you attempt to allocate the same record with the second.
Have you tried to display the record locks using DSPRCDLCK ?
Are you using OVRDBF SHARE(*YES) ?
It might be the cause. IMHO developers have never understood to use this in a proper way and I avoid the use of it.
It might be a help if you could show us an anonymized version of the program.Comment
-
To better describe my situation, I have a program which deletes sales orders. The last thing it does is to check if there are any back-orders for the one deleted, and if not deletes some ancillary data. This check is when the SETLL/READE comes in.
The program trying to get a record lock prints a pick list, to mark the order as pick-list-printed. I'm positive the two programs are not accessing the same order.
This problem occurs infrequently, but it always involves the same two programs. The order delete is interactive, the pick list print runs in batch.
I just learned about the DSPRCDLCK command, and will use it the next time this happens. The file is not shared.
Comment
-
Are you using Commitment Control perhaps?Comment
-
I assume that the interactive program have established the record lock and program in the batch job is
waiting to get a lock.
First I would take a look at the code in the interactive program. Is there some way that it could establish a lock
without releasing the record again? Or has it to do with the fact that a record is read and locked and then waiting
for some input to be done on the screen before updating and releasing the record?
Second take a look at the batch program. When waiting for a record lock, is the current record the record just before
the record the interactive program has a lock on?
Suppose the situation is like this where the X, Y and Z represents the partial key in the file:
XXXXXXX
XXXXXXX
XXXXXXX <----- batch program has a lock on this reading all records with the partial key XXXXXXX
YYYYYYY <----- interactive program has a lock on this
YYYYYYY
ZZZZZZZ
When the program tries to read the next record with the partial key XXXXXXX then there are no more records and an
EOF should occur. BUT before that it tries to lock the record YYYYYYY temporarily which is not possible because
it is already locked by the interactive program !
This is the situation I described in an earlier post.
And given the information you have given us, I assume that this is the cause to your problems.
Best fix is to read the records with READE(N) and the CHAIN the record when it needs to be updated.
Comment
-
It is the interactive program that has a lock on a record, and the batch program needs that record for update. This I know because of the error message sent from the batch program.
XXXXXXX <-------- Interactive program has deleted this record. Following the delete, it does a SETLL/READE on XXXXXXX.
YYYYYYY <-------- Batch program tries to read this record for update, but it is locked by the interactive program.
The above implies that YYYYYYY is the next key in sequence after XXXXXXX. I do not know this. I do not know the value of the key for the record deleted, nor the value of the key for the pick-list print. What I do know is the SETLL/READE is the only time in the interactive program where a record is read for update without a following unconditional DELETE or UPDATE.
My initial thought was, if YYYYYYY is the next key in sequence after XXXXXXX and the interactive program holds a lock even when the result is EOF, this would explain why the batch program cannot get the record lock it needs. In this case a READE(N) would solve the problem. But the consensus is that the EOF result will release any locks.
I will wait for this to happen again, and try to obtain the key values used by the two programs.
Thanks all for your help.
Comment
Comment