Kbase P109264: The rereadnolock startup parameter explained
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
1/19/2006 |
|
Status: Unverified
GOAL:
The rereadnolock startup parameter explained
GOAL:
Explaining the rereadnolock parameter.
GOAL:
How the rereadnoclok works?
FIX:
Assuming the following code:
def buffer c1 for customer.
find c1 where cust-num = 10 no-lock.
.... some code
for each customer no-lock:
.... more code
end.
In the database, there is exactly one record for customer 10. When that record is updated, there is still one record for customer 10. That record's rowid will not change for the life of the record, even if the customer number is changed. Similarly, in session's 4gl interpreter memory buffers, there can be only one copy of a given record, regardless of how many 4gl buffers may exist. Record identity is established by rowid.
When the find statement is executed, the record for customer 10 is retrieved from the database. It is held in an internal buffer called an "icb". The icb is tagged with the rowid and table number of its contents. The 4gl program's buffer c1 is linked to that icb.
As the for each loop is executed, the customer records are fetched one at a time into an icb and the 4gl program's customer buffer is linked to that icb. When the loop gets to customer 10 and fetches it, there is already an old copy of that record (the rowid matches). A choice will have to be done on which one to use, the old one or the new one.
If the lock types are not the same, the one with the higher lock type will be chosen.
If the lock types are the same and both are share, it doesn't matter which one is chosen as the records must both have identical contents.
If the lock types are the same and both are exclusive, then we will use the older one because we might have updated it, but it might not yet have been written back to the database. The new one can't have been updated because we just fetched it and our 4gl example hasn't had a chance to touch it yet.
If the lock types are /both no-lock/, then rereadnolock comes into effect. Since the record was originally fetched without a lock, it is possible that someone else has updated the record. In the original 4gl design, the older copy of the record was chosen because it was thought that it was better to see the same version of the record that you originally fetched. In other words, here are some measure of read consistency even though the record was not locked.
The rereadnolock option says "to see the newer version of the record" so that one will be used. Progress didn't make it the default behavior because doing so would have broken some existing applications.
There is no extra database activity involved when using rereadnolock. It is not known if we already have the record until we get it back from the database and find a match on the rowid with an icb containing a previously fetched record.