Re: IBM Debunks Oracle's MultiVersion Read Consistency ?

On Sun, 20 Apr 2003, rallen_at_NOSPAMOKhgi.com wrote:

> They raise some good points. Is it really as efficient as IBM
> suggests? What are the advantages that MVRC provide?

The thing that struck me as silly is that they crow about supporting ReadUncommitted. Why is this ever a good thing (except when you might be blocking and need some way to move one, ala SQLServer and it sounds like DB2) If you read any uncommitted data and then after you've read it the writer of that data rollsback, then what good was the read?

I like the fact that Oracle says, whatever is committed is boss, period.

Others?

    Even committed transactions are not seen by the reader if the reading     statement started before the updating statement.

I think Oracle chose the correct way to go. If a row you already read gets updated before you are done with your full read, what should your answer contain?

    To get around this well known Oracle problem, application developers     will write their applications and commit as infrequently as     possible.

Eh? Oracle allows us to commit when the business logic says so, period.

    Oracle's concurrency model is page based.

So. The problem there is they try to say that both transactions can't proceed when they are blocking different rows on the same page. All this says to me is that Oracle only writes out pages, therefore it will have multiple versions of the same pages based on the concurrency needs. Lumping it together to try and imply Oracle's transactions block readers is just devious.

-- 
Galen deForest Boyer
Sweet dreams and flying machines in pieces on the ground.