Re: Changing isolation level? ++ scenarios

"Daniel Morgan" <damorgan_at_x.washington.edu> wrote in message news:1070661749.195771_at_yasure...
> Joel Garry wrote:
>
> > vslabs_at_onwe.co.za (Billy Verreynne) wrote in message
news:<1a75df45.0312042357.5c158776_at_posting.google.com>...
> >
> >>The bottom line IMO is information. Provide the business with
> >>information in order for them to make their decisions. Isolation
> >>levels are not an issue - not if you use Oracle correctly and not if
> >>you design your app & database correctly.
> >
> >
> > That's correct as far as it goes, but one of the OP's points was that
> > it was designed correctly, and has been proven in the business for
> > years. So he's asking how to use Oracle correctly to do what has been
> > designed correctly, and unfortunately the answer is as hjr pointed
> > out. Another way of saying it is, Oracle's design tradeoffs make this
> > particular issue difficult to work with using Oracle's normal design
> > constraints.
> >
> > jg
> > --
> > @home.com is bogus.
> > The fan hits the crap:
> > http://www.cnn.com/2003/US/West/12/04/blimp.crash/index.html The
> > "ground" they refer to was actually a pile of manure.
>
> I completely disagree with your analysis. Turn the situation around and
> you'll see why.
>
> Suppose the original application had been built in Oracle where is was
> designed to be compatible with reads not blocking writes, writes not
> blocking reads, no lock escallation, etc. It too would work perfectly.
>
> Then you would try to rehost on another RDBMS and you'd have the exact
> same complaint.
>
> The point is not that one is right and one wrong. Not that one is better
> and one worse. Rather that each is different and intelligent people read
> the Concepts books, read the Architecture books, and make modifications
> to optimize their work for the tool they are using. Same as there is
> nothing that makes screws better than nails but you won't get very far
> trying to get nails into a 2x4 with a screwdriver.

I think my point was a bit simpler than that: there is no choice in Oracle. You get multi-versioning, and that's your lot. If even SQL Server (as Mark suggests) is about to offer the choice of block/dirty read/read consistency, then Oracle ought to consider doing the same. Clever as their read consistency model is, it's not the only show in town, and Oracle ought to realise that.

There are perfectly good business reasons for wanting to read dirty data. There are perfectly good business reasons for wanting blocking locks. There are perfectly good business reasons for wanting no blocking and read consistent images of data. Oracle satisfies only one of those requirements.

I have always disliked the suggestion that my business requirements are stuffed, and the technology is just fine. That puts the cart before the horse, and ignores the fact that technology is there to serve my business requirements, and not the other way around.

More choice in strategy, please, Oracle.

Regards
HJR

-- 
------------------------------------
Oracle insights at www.dizwell.com
------------------------------------