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

The system I'm working on has had to deal with these types of issues for a long time, as have all systems that do sophisticated things with inventory, have been around for a while, and run on multiple db's. One can laugh at the implicit lowest-common-denominator code and theoretically screwy transaction handling (I often do!), but in the end it does in vivo prove that there is a good business case for apps that run the same in different environments. In the hjr example, there winds up being a trap for the lock, so the program can handle it however the business rules require, the default being to try a configurable amount of times, then ask if you want to continue trying.  This comes out of relational code from the era before SQL was... the de facto data interchange language?!?

So if the OP's system has been well-proven to, say, minimize overallocation of finite resources, it can make a lot of sense to write code that is screwy from an Oracle point-of-view, rather than try to reengineer it for the technology. One just has to be cognizant of the unusual operational issues that will surely come up.

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

jg

--
@home.com is bogus.
Time to rewrite all documentation politically correct:
http://www.reuters.com/newsArticle.jhtml?type=topNews&storyID=3894931