Re: Newbie's Oracle 9i impression: it sucks

In article <3CEC0EFC.1CFC61D5_at_ca.ibm.com>, you said (and I quote):
> session 2 comes back and updates some values in big_orders (or an other table to
> make things worse) using its old version of orderids.
> Isn't that wrong? The problem with multi versioning is that the DML always is on
> the current version while the data you read is on an old version.

Not necessarily. What you do is you read a particular version. If you weally,weally want to update the data later on, you MUST re-read with lock and verify if still the same. Then you can update confidently. Otherwise you don't know what you're updating is what you read before. And the re-read with lock will make sure you have exclusive access for your (supposedly) vewy vewy fast update.

> If the application didn't get coded with session 3 in mind bad things can happen
> here.

Sure.

> I wouldn't go as far as saying that any one locking scheme is right or wrong.
> They all have their places. But "readers don't block writers" is not better.
> It's just different.

Yeah, but at least with "readers don't block writers and writers don't block readers" I can still run my weekly or daily aggregates with confidence the result WILL make sense without me having to lock out the entire table(s). No other locking or concurrency scheme can provide that. Important? Yes, when your daily aggregates number in the millions of $$$ of transactions...

>
> Cheers
> Serge
>
> PS: I apologize for the technical content ;-)

Now now, we MUST NOT break with Usenet tradition!!!!

<quick, some non-sense: ¦Þ~~~ >
:-D

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