Re: Changing isolation level?

Howard J. Rogers wrote:
> "mcstock" <mcstock @ enquery .com> wrote in message
> news:[EMAIL PROTECTED]
>
> > "Hemant Shah" <[EMAIL PROTECTED]> wrote in message
> > news:[EMAIL PROTECTED]
> > | 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

playing Angel's Advocate of course we're left with ...

1. Miss Marple's credit card is over her limit so Fred cancels the sale 
that was in progress.  Wait, we really do have 1 in stock.

2. There wasn't a sale in progress so I told Mrs. Miggens we had 1 in 
stock.  Immediately after hanging up, Fred gets the call from Miss 
Marple and sells the turbo-widget.  The customer is in the same position.

There seems to be very little (if any) business benefit in this 
scenario.  Besides the lost productivity of your sales staff...  "I'm 
sorry Mrs. Miggens, can you please hold for 5 minutes or so while my 
buddy Fred finishes or cancels his order and then I'll get you what 
should be an accurate answer at that instant in time (unless someone 
else starts another order) but you better get over here fast after all 
that or it might still be sold".

--
Richard Kuhler