Re: Changing isolation level?

"Mark Townsend" <markbtownsend_at_attbi.com> wrote in message news:OzAzb.297849$9E1.1521225_at_attbi_s52...
> When you boil it down, all of these scenarios are actually business
> problems, not technology problems.

Bit of a cop out there Mark, I think.

Business only use technology to solve their problems, so at the end of the day, it's all a technology problem.

So, let me ask you: what's the answer to my problem. Should I see stock level zero, stock level 1, or stock level God Knows because it's changing right now?

Sure, that's a business issue, and different businesses will resolve it in different ways. But the Oracle database sure as hell won't.

And that's the issue (but not one I lose a heap of sleep over, to be honest): Oracle provides only one answer, yet different businesses might require different answers. Which means that Oracle is the wrong technology solution for x% of the market.

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

But the point is, we don't have much of a choice on the isolation level in Oracle!

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

That's a business cost (eg, excessive stock levels) to address a technology failing. Not good enough.

> 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 works brilliantly, and you won't hear me arguing anything else, very much. But it's a one-shot model: our method is right, and everything else is wrong (or not available, which amounts to the same thing), and if your business needs don't fit that model, we suggest you sod off and try another product. Mmmm. Not utterly endearing as a marketing approach.

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

So let me get this right. SQL Server, which has long had the lock-or-read-dirty strategy is going to embrace the read-consistency model (though God knows how they'll pull that off)? Good news. So when will Oracle, long-time owners of the read-consistency model, provide the lock-or-read-dirty option? It's only technological choices, after all... so how about giving us some??

Regards
HJR
>
> 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:58:58 CST