Re: Article about supposed "murky" future for Oracle

"rkusenet" <rkusenet_at_sympatico.ca> wrote in message news:<c4hb6k$2gi5gl$1_at_ID-75254.news.uni-berlin.de>...
> "Daniel Morgan" <damorgan_at_x.washington.edu> wrote in message news:1080798723.472164_at_yasure...
>
> One thing I have noticed is that all examples given by Oracle folks
> here to prove their point involves taking a rare case like humungous query.

not so. my example used 3 rows - 3 rows.

Your choices in read lock databases:

1. use read committed and get the wrong answer
2. use repeatable read/serializable and either
3. deadlock with an update transaction, one of you loses
4. block the update for a period of time or get blocked and get the right answer

three rows.

> How many of us would be issuing update command involving thousands of
> rows during peak production hours to a heavily used table. In case of

how many of us run reports on a system that aggregates data whilst others are modifying it?

How many of the developers understand they are getting results that never existed in the database at any point in time (they would not use RR or Serializable -- they experienced those deadlocks and figured "bad idea")

Worse yet, how many end users understand that what they are seeing could be something that never existed.

These are not made up, these are reasons I've worked with people to port from database A to database B.

> Oracle, since it has to write twice to the block, once for lock and
> once for the data update, I am not sure how much performance impact

only if you select for update -- which if you want to not have "lost updates", you might consider doing in some but not all cases. Like you say -- it depends. Received on Fri Apr 02 2004 - 15:03:28 CST