And that paper *got it slightly wrong*

Beginning with Oracle version 4 (before firebird - aka interbase) Oracle incorporated the idea of MVCC.

</code> http://asktom.oracle.com/Misc/something-different-part-i-of-iii.html#c112584079541388964 <code>


The implementation is pretty much the "same", 9ir1 added automatic undo management to curtail the chance of a 1555, but that is the "biggest" change in a long time.

read consistency in Oracle has been achieved via Multi-Versioning.

Others do it via shared or exclusive locks.

I cannot remember that far back ;)

I'll ask him!

and he said...

We indeed had multiversioning in V3. We had a separate Before Image (BI) file that had old block copies. It was used to provide non-blocking reads, and avoid read-write contention. However, for some reason I don't recall exactly, we didn't apply read consistency to indexes, or properly stop a scan or something. I would have to think harder to recall the precise details (and maybe I'm too old to ever remember precisely!).

A statement would see its own changes in a funny way. Thus, a statement like this

insert into emp
select * from emp

would in fact read the very rows it was inserting and with 14 rows in EMP you might end up with either an infinite loop (I don't recall that ever happening) or some "random" (unpredictable) number of rows!

it is all in the implementation - we'll have to wait and see how their implementation, which works like our workspace manager (they version rows, in the table - sort of like a flag delete) holds up.

I've a feeling it'll still be valid.