Re: Oracle read consistency *inside*a transaction

VC wrote:
> Please see below:
>
> [AF]
> <afilonov_at_yahoo.com> wrote in message
> news:1102377411.931512.29600_at_f14g2000cwb.googlegroups.com...
> > True, but irrelevant for the transaction itself. It doesn't do
> > consistent
> > read in this case. It would if other transactions modified the
block,
> > but
> > you said it's not the case. For the session in which transaction
> > happened, all changes done by this transaction are visible, i.e.
there
> > is no need for rollback.
>
> [VC]
> Oracle performs intra-transactional 'mini'-rollbacks aka 'consistent
reads'
> in several cases:
>
> 1. A failed update/delete/insert statement.
> 2. savepoint ... rollback to.
> 3. apparently in the case I described in my original message.
>
> It's sort of obvious that no other transaction is involved during
those
> 'consistent reads' in order for them to qualify as such.
>
> [VC]
> >
> >> The rest of your response is skipped as irrelevant.
> >>
> >
>
> [AF]
> > Well, why are you asking then?
> >
>
> [VC]
> I asked hoping to get some insight into how Oracle distinguishes
between
> two different changes in the same transaction. My assumption was
that
> Oracle performed a mini-rollback in order to get the previous row
value.
> What I do not understand is how exactly it's implemented since an SCN
can
> not be used as a 'timestamp' inside the same transaction.
>
> Unfortunately, your remarks were, as said, largely irrelevant. In
case I
> missed something of value in your response, I apologize.
>

OK.

"Timestamps" for uncommitted transaction, as well as any other transactional information, is stored in internal transaction tables (that's why I referred you to Concepts Manual, it's all described there).

> Thanks.
Received on Tue Dec 07 2004 - 12:20:24 CST