Re: Changing isolation level?

From: Mark Townsend <markbtownsend_at_attbi.com>
Date: Thu, 04 Dec 2003 06:34:23 GMT
Message-ID: <OzAzb.297849$9E1.1521225@attbi_s52>

When you boil it down, all of these scenarios are actually business problems, not technology problems. No matter what isolation level you use, you will still need to solve the problem of over allocation of finate resources with a suitable business practice.

It is for these reasons that inventory systems typically maintain a minimum re-order level, air lines regularly overbook planes by 20%, and banks provide overdrafts.

Oracle, by design, uses a locking strategy that is different from other databases, and does take some getting use to for people that come from other database environments. But it does work, and it does work well.

It's also of interest that the forthcoming Yukon version of SQL Server will introduce a new type of isolation level, that they are calling snapshot isolation, which looks at first blush to be very similar to the Oracle model.

Howard J. Rogers wrote:
> "mcstock" <mcstock @ enquery .com> wrote in message
> news:OYydnYF8d4uguVCiRVn-sA_at_comcast.com...
>

>>"Hemant Shah" <shah_at_typhoon.xnet.com> wrote in message
>>news:bqj76t$f47$1_at_flood.xnet.com...
>>| While stranded on information super highway mcstock wrote:
>>| :)refer to the SET TRANSACTION statement in the SQL Reference manual
>>| :)
>>| :)relevant options are: ISOLATION LEVEL SERIALIZABLE and ISOLATION LEVEL
>>READ
>>| :)COMMITTED (default)
>>| :)
>>| :)doesn't look like ISOLATION LEVEL SERIALIZABLE does what you want
>>| :)
>>| :)
>>| :)you'll also want to carefully review the sections on Data Concurrency
>>and
>>| :)Consistency in the Concepts manual
>>| :)
>>|
>>|
>>|  As others have mentioned, none of the isolation level will block

>
> readers.
>

>>|  I will have to find some other way.
>>|
>>
>>why do you need to block readers?
>>what is the business benefit?
>>is it just to make oracle look like DB2?
>>
>>if you can describe a business benefit and the required behavior from a
>>application functionality standpoint, i'm sure a number of folks can come

>
> up
>

>>with suggested approaches.

>
>
>
> Time to don the Devil's Advocate costume, I think.
>
> I can think of lots of cases where it would be rather unfortuate to see an
> old piece of data just prior to it being changed. Rather than see the old
> data, I could well imagine that it would be more helpful to see nothing
> until the situation stabilises.
>
> If I have a customer demanding to know whether I have a turbo-widget in
> stock, I can select from my products table to check. It tells me I have one
> such item left. Mrs. Miggens therefore, on the strength of that, undertakes
> the arduous two-hour journey from remote rural New South Wales into the City
> Centre to pick up said turbo-widget. Unbeknownst to her, however, the
> information I gave her was wrong, because at the time I did my query, Fred
> in the next cubicle was selling the same product to Miss Marple. He hadn't
> committed the transaction, which is why I saw a stock level of 1. But it
> would have been nice not to give the wrong info out to Mrs. Miggens. I
> suppose I could have badgered her into placing an order, because then my
> attempt to update the stock level myself would have failed. But Mrs. Miggens
> ran into a bit of credit rating trouble a while back, and doesn't have a
> credit card. The most she can do on the phone is to enquire.
>
> There are two choices there, I suppose: see nothing at all (the blocking
> idea). Or see a stock level of 0 (the dirty reads issue beloved of, er,
> certain other products). Oracle's long-time answer has been: you'll see 1,
> and only 1, and nothing else, ever... which some might consider to be a lack
> of choice in answering technology.
>
> Regards
> HJR
>
>
>
>
>
Received on Thu Dec 04 2003 - 00:34:23 CST