Re: About read consistency

From: Maxim Demenko <mdemenko_at_gmail.com>
Date: Fri, 16 Dec 2005 09:43:38 +0100
Message-ID: <dntunj$ng0$03$1@news.t-online.com>

Mladen Gogala schrieb:
> On Thu, 15 Dec 2005 19:42:36 +0100, Maxim Demenko wrote:
>
>

>>I've the same behaviour on 9.2.0.6 and 10.2.0.1 on Linux and on 9.2.0.6 
>>on Solaris. Is it a (maybe well known) bug, or did i overlook something 
>>obvious ?
>>All insights appreciated.
>>
>>Best regards
>>
>>Maxim

>
>
> You overlooked so called "write consistency". Yes, transaction "B" should
> not return any data before it has begun, but the transaction finds that
> the records that it was waiting on were modified while it was waiting.
> Transaction is then re-started and now the commit point is no longer
> before the transaction start. Therefore, you will get back all rows.
> It's an expected behavior, described in Tom Kyte's book.
>

Mladen, thank you for the answer, but i don't think, it explains the question.
I thought, exactly due to reason you mentioned, the transction "B" should have been restarted, should discover that no more rows satisfy the where clause and should return no rows back ( as it does in scenario 1) . But it returns (as if Oracle don't know, the records have been modified).

I suggest , the problem ( if there is one, of course) is caused by the subquery, if i exclude subquery, i can't reproduce anymore the "unexpected" behaviour.

By Tom Kyte, if you mean the example about repeatable read from "Expert one on one", describes exactly the first scenario ( i've stated too, it is expected behaviour).

Best regards

Maxim Received on Fri Dec 16 2005 - 02:43:38 CST