Re: Article about supposed "murky" future for Oracle

"Serge Rielau" <srielau_at_ca.eye-be-em.com> wrote in message news:c4cso4$hqu$1_at_hanover.torolab.ibm.com...

> There is no such thing as a free lunch. The versioning comes at a cost
> too. Pushing a version and managing the rollback segments is not for free.
> Neither is finding the appropriate version for each row.
> The concept works well if the stack is fairly small.

You know Serge, every once in a while you folks at IBM sit down and follow the motto of your company: "think". I'll say no more as Mr. Ellison might beat me around a few times (even though he's got nothing to do with me) if I opened my mouth on this one...

> You can look at it from another angle:
> If I need to look at a row and it is currently being updated. How do I
> gamble? If I presume the update will commit then looking at old data
> will result in a decision being made on stale data. That can be bad.
> On the flip side, I can read uncommited data in most RDBMS and go wrong
> when the transaction on which's success I depend rolls back.
> I wouldn't want to state one isolation level is better than the other.

Serge, Serge, Serge..... Here we go again into marketing mode. You were doing so well, darn it! You folks have to start reading your own materials and prior literature on this problem, its nothing new. But insisting on hiding the thing just because DB2 can't provide the feature is IMHO silly in the extreme.
Read some of the materials about databases and locking that IBM put out ages ago,
in the dinossaur times.

Sorry, all patronising childish crap aside: let's step back into technical reality for a second. The problem has got NOTHING to do with uncomitted data, serialisation, yadda yadda. That is all marketing crap from the rubbish people call modern IT and "OODB"/multi-tier/crap.

The problem is VERY simple, it was stated ages ago and NOTHING has changed in what is fundamentally a queueing theory problem:

You must NOT, EVER!!!!! read uncomitted data ****IF**** you are planning to change it in the same transaction.

In simple words: if you plan to change a set of data, you LOCK it WHEN you read it!

Simple. Common to EVERY single database that purports to have a locking mechanism and concurrent multi-user access. Please: let's not waste time arguing this. It is obvious, has been worked out ages ago and has NOTHING to do with Oracle's versioning, "serialising" or whatever else crap.

Now, ****IF**** you want to CONCURRENTLY (with your updates) read ****CONSISTENT**** sets of data (as in producing reports or running long queries), then you MUST have some mechanism to ensure those sets of data are consistent from the point in time you START reading them, to the point in time you finish reading them. Set at a time.

Otherwise, it is only too easy for another transaction's update to CHANGE data you haven't yet read and all Hell breaks loose.

It's in ALL the classic texts, you should know this already: I hate to have to talk to granny about sucking eggs!

Two ways you can achieve this Holy Grail: with writers blocking readers, or with versioning. It's all about which one is easier to use from the point of view of the poor blighters writing the application code.

I know which one I'd choose. PARTICULARLY when the database locks on blocks (pages) rather than true row locking. But we don't need to go there right now.

> The only truly safe isolation level is serializable (which matches
> Repeatable Read in DB2 I think) any other isolation level has drawbacks
> that the app has to be aware of.

No. Incorrect. And completely ignoring the reality of data processing. Versioning has NOTHING to do with isolation levels and it solves the problem in a TRANSPARENT fashion.

> PS: I always thought WallStreet was/is a Sybase Stronghold obviously
> Banks could live with what Sybase has to offer.

Banks will live with whatever is cheaper. Period.

-- 
Cheers
Nuno Souto
wizofoz2k_at_yahoo.com.au.nospam