Re: Changing isolation level? ++ scenarios

From: Daniel Morgan <damorgan_at_x.washington.edu>
Date: Fri, 05 Dec 2003 14:53:49 -0800
Message-ID: <1070664860.494943@yasure>

Howard J. Rogers wrote:

> "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
>

I would agree if someone would point out the value in allowing a dirty read. I understand that if that is all you've got you do your best to be like Oracle. But why would Oracle introduce something without value to Performance? None: Scalability? None: Data Integrity? None.

Show me the beef.

-- 
Daniel Morgan
http://www.outreach.washington.edu/ext/certificates/oad/oad_crs.asp
http://www.outreach.washington.edu/ext/certificates/aoa/aoa_crs.asp
damorgan_at_x.washington.edu
(replace 'x' with a 'u' to reply)

Received on Fri Dec 05 2003 - 16:53:49 CST