Concurrent Reads

[Subhransu]

Hi All,
I would like to know what happens when a user tries to fetch a record in NO-LOCK which is being modified by another user at the same time but not been comitted till then? In other words, whether the user who wants to read that record will get a record which is not logically consistent or he will get the previously comitted data?

Thanks.
Subhansu

 

[rzr]

hum... did you try testing / replicating this scenario ?? I'm sure you will have your answer - if you do it..

 

[RealHeavyDude]

NO-LOCK is always a dirty read. It will always retrieve the record as is.

To answer your question: It depends.

It depends

• whether an optimistic or pessimistic locking strategy is utilized when updating data in the database.
• whether buffer and transactions scope are relative to each other ( transaction scope could be larger than buffer scope, therefore the record will be flushed to the database and will still be locked until the transaction is either committed or rolled back ).
• whether a RELEASE statement gets executed relative to buffer and transaction scope (BTW, RELEASE is bad, bad, bad, bad practice ).
• how the values are assigned ( in a single statement in a single block versus scattered over several statements in different blocks ).
• on the transaction size ( the smaller the transaction the faster it should get through and the less time remains for another client to fetch the record in that time window ).

You see there is no one-size-fits-all answer to your question. Out of experience I would say that in most applications the answer is YES. Yes - these applications do not utilize buffer and transaction scope, assignments and locking strategy in a way that would prevent or make it highly unlikely for another client to retrieve a record in an intermediate state.

Heavy Regards, RealHeavyDude.

 

[rzr]

muito bem !!

 

[Casper]

And then there is also -rereadnolock parameter. If you are not using it you might get the previous record even though the change is already fully committed.

Regards,
casper.

 

[GregTomkins]

This (lack of MVCC / a READ-COMMITTED option) is a major conceptual flaw of Progress, IMHO, and (again IMHO) there is no way around it that is both bulletproof and practical.

On the other hand, I've been hacking Progress for going on 20 years, and I have yet to see a single real-world problem / customer complaint caused by it.

 

[TomBascom]

On the other hand, I've been hacking Progress for going on 20 years, and I have yet to see a single real-world problem / customer complaint caused by it.

Exactly. 25 years and never a customer issue...